Re: libpq error message refactoring
От | Tom Lane |
---|---|
Тема | Re: libpq error message refactoring |
Дата | |
Msg-id | 2032645.1663900649@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: libpq error message refactoring (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: libpq error message refactoring
|
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > On 22.09.22 17:42, Andres Freund wrote: >> It's not the cause of this failure, I think, but doesn't appendPQExpBufferVA >> need to be added to exports.txt? > I don't want to make that function available to users of libpq, just use > it inside libpq across .c files. Is there no visibility level for that? Should "just work", I should think. I agree with Andres that that's not the cause of the build failure. I wonder if somehow the failing links are picking up the wrong libpq.a. Separately from that: is it really okay to delegate use of a va_list argument like that? The other call paths of appendPQExpBufferVA[_internal] write va_start/va_end directly around it, not somewhere else in the call chain. I'm too tired to language-lawyer out what happens when you do it like this, but I'm suspecting that it's not well-defined portable behavior. I think what you probably need to do is export appendPQExpBufferVA as-is and require libpq_append_error to provide the error loop. regards, tom lane
В списке pgsql-hackers по дате отправления: