Re: making the backend's json parser work in frontend code
От | Tom Lane |
---|---|
Тема | Re: making the backend's json parser work in frontend code |
Дата | |
Msg-id | 18144.1580236346@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: making the backend's json parser work in frontend code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: making the backend's json parser work in frontend code
|
Список | pgsql-hackers |
I wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Is the example of CreateDestReceiver() sufficient to show that this is >> not a problem in practice? > Dunno. I don't see any warnings about that in the buildfarm, but > that's not a very large sample of non-gcc compilers. BTW, now that I think about it, CreateDestReceiver is not up to project standards anyway, in that it fails to provide reasonable behavior in the case where what's passed is not a legal value of the enum. What you'll get, if you're lucky, is a SIGABRT crash with no indication of the cause --- or if you're not lucky, some very hard-to-debug crash elsewhere as a result of the function returning a garbage pointer. So independently of whether the current coding suppresses compiler warnings reliably, I think we ought to replace it with elog()-and-return-NULL. Admittedly, that's wasting a few bytes on a case that should never happen ... but we haven't ever hesitated to do that elsewhere, if it'd make the problem more diagnosable. IOW, there's a good reason why there are exactly no other uses of that coding pattern. regards, tom lane
В списке pgsql-hackers по дате отправления: