Re: [PATCH] Make jsonapi usable from libpq

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Make jsonapi usable from libpq
Дата
Msg-id 335902.1624907747@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Make jsonapi usable from libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Make jsonapi usable from libpq  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
I wrote:
>> Not real sure what to do about PGTHREAD_ERROR.

> I wonder if we shouldn't simply nuke that macro and change the
> call sites into "Assert(false)".

After further study this still seems like the best available choice.
We do not have the option to make either default_threadlock() or
pq_lockingcallback() do something saner, like return a failure
indication.  pq_lockingcallback()'s API is dictated by OpenSSL,
while default_threadlock()'s API is exposed to users by libpq
(IOW, we could have gotten that one right years ago, but we
failed to, and it seems much too late to change it now).

Also, I trawled the mailing list archives, and I can find no
indication that any of the PGTHREAD_ERROR messages have ever
been seen in the field.  The last relevant discussion seems
to be in

https://www.postgresql.org/message-id/flat/20130801142443.GO2706%40tamriel.snowman.net

where it was observed that this code isn't very well thought
through :-(

My proposal is to replace PGTHREAD_ERROR by Assert(false)
in HEAD, but leave things alone in the back branches.

As far as the other patch to check for mistakes with "nm"
goes, we could either do nothing in the back branches, or
install a check for "exit" only, not "abort".  But there's
probably no real need for such a check in the back branches
as long as we're enforcing it in HEAD.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: A qsort template
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Rename of triggers for partitioned tables