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
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 during development and translation. So I looked into
whether we
13 matches
Mail list logo
