On 2022-Nov-13, Peter Eisentraut wrote:
> On 09.11.22 13:29, Alvaro Herrera wrote:
> > > + /* Loop in case we have to retry after enlarging the buffer. */
> > > + do
> > > + {
> > > + errno = save_errno;
> > > + va_start(args, fmt);
> > > + done = appendPQExpBufferVA(error
On 09.11.22 13:29, Alvaro Herrera wrote:
+/*
+ * Append a formatted string to the given buffer, after translation. A
+ * newline is automatically appended; the format should not end with a
+ * newline.
+ */
I find the "after translation" bit unclear -- does it mean that the
caller should have
Hello
I gave this series a quick look. Overall it seems a good idea, since
the issue of newlines-or-not is quite bothersome for the libpq
translations.
> +/*
> + * Append a formatted string to the given buffer, after translation. A
> + * newline is automatically appended; the format should not
On 23.09.22 04:37, Tom Lane wrote:
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
On 23.09.22 04:45, Andres Freund wrote:
On 2022-09-22 19:27:27 -0700, Andres Freund wrote:
I just noticed it when trying to understand the linker failure - which I
still don't...
Heh, figured it out. It's inside #ifdef ENABLE_NLS. So it fails on all
platforms without NLS enabled.
Hah!
Here
Andres Freund writes:
> Heh, figured it out. It's inside #ifdef ENABLE_NLS. So it fails on all
> platforms without NLS enabled.
Argh, how simple!
The question about va_start/va_end placement still stands, though.
regards, tom lane
Hi,
On 2022-09-22 19:27:27 -0700, Andres Freund wrote:
> I just noticed it when trying to understand the linker failure - which I
> still don't...
Heh, figured it out. It's inside #ifdef ENABLE_NLS. So it fails on all
platforms without NLS enabled.
Greetings,
Andres Freund
Andres Freund writes:
> I suspect the appendPQExpBufferVA is orthogonal - most (all?) of the other
> functions in pqexpbuffer.h are visible, so it feels weird/confusing to not
> make appendPQExpBufferVA() available.
I thought the same to start with, but if I'm right in my nearby reply
that we'll
Peter Eisentraut 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
HHi,
On 2022-09-22 22:00:00 -0400, Peter Eisentraut wrote:
> On 22.09.22 17:42, Andres Freund wrote:
> > This patch has been failing for a while:
> > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/3854
> >
> > Interestingly, previously the error only happened when targetti
On 22.09.22 17:42, Andres Freund wrote:
This patch has been failing for a while:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/3854
Interestingly, previously the error only happened when targetting windows, but
meson also shows it on freebsd.
It's not the cause of this
Hi,
On 2022-08-25 16:34:26 +0200, Peter Eisentraut wrote:
> libpq now contains a mix of error message strings that end with newlines and
> don't end with newlines, due to some newer code paths with new ways of
> passing errors around. This has now gotten me confused a few too many times
> both du
12 matches
Mail list logo
