On Thu, Jul 29, 2021 at 9:57 AM Tom Lane wrote:
> In the case at hand, I'd personally avoid a ternary op for the first
> assignment because then the line would run over 80 characters, and
> you'd have to make decisions about where to break it. (We don't have
> a standardized convention about that
Andrew Dunstan writes:
> On 7/29/21 3:01 AM, Peter Smith wrote:
>> I've seen lots of code like this where I may have been tempted to use
>> a ternary operator for readability, so I was wondering is there a PG
>> convention to avoid such ternary operator assignments, or is it simply
>> a personal t
Em qui., 29 de jul. de 2021 às 04:02, Peter Smith
escreveu:
> (This is not a code review - this is just to satisfy my curiosity)
>
> I've seen lots of code like this where I may have been tempted to use
> a ternary operator for readability, so I was wondering is there a PG
> convention to avoid s
Em qui., 29 de jul. de 2021 às 00:40, Tom Lane escreveu:
> Ranier Vilela writes:
> > IMO, I think that "char *msg" is unnecessary, isn't it?
>
> > + if (!PQExpBufferBroken(errorMessage))
> > + res->errMsg = pqResultStrdup(res, errorMessage->data);
> > else
> > - res->errMsg = NULL;
> > + res->
On 7/29/21 3:01 AM, Peter Smith wrote:
> (This is not a code review - this is just to satisfy my curiosity)
>
> I've seen lots of code like this where I may have been tempted to use
> a ternary operator for readability, so I was wondering is there a PG
> convention to avoid such ternary operator
(This is not a code review - this is just to satisfy my curiosity)
I've seen lots of code like this where I may have been tempted to use
a ternary operator for readability, so I was wondering is there a PG
convention to avoid such ternary operator assignments, or is it simply
a personal taste thin
Ranier Vilela writes:
> IMO, I think that "char *msg" is unnecessary, isn't it?
> + if (!PQExpBufferBroken(errorMessage))
> + res->errMsg = pqResultStrdup(res, errorMessage->data);
> else
> - res->errMsg = NULL;
> + res->errMsg = libpq_gettext("out of memory\n");
Please read the comment.
Em qua., 28 de jul. de 2021 às 21:25, Tom Lane escreveu:
> I wrote:
> > Andres Freund writes:
> >> Hm. It seems we should be able to guarantee that the recovery path can
> print
> >> something, at least in the PGconn case. Is it perhaps worth pre-sizing
> >> PGConn->errorMessage so it'd fit an e
I wrote:
> Andres Freund writes:
>> Hm. It seems we should be able to guarantee that the recovery path can print
>> something, at least in the PGconn case. Is it perhaps worth pre-sizing
>> PGConn->errorMessage so it'd fit an error like this?
>> But perhaps that's more effort than it's worth.
> Y
Andres Freund writes:
> Hm. It seems we should be able to guarantee that the recovery path can print
> something, at least in the PGconn case. Is it perhaps worth pre-sizing
> PGConn->errorMessage so it'd fit an error like this?
Forgot to address this. Right now, the normal situation is that
PGC
Andres Freund writes:
> I should probably know this, but I don't. Nor did I quickly find an answer. I
> assume gettext() reliably and reasonably deals with OOM?
I've always assumed that their fallback in cases of OOM, can't read
the message file, yadda yadda is to return the original string.
I ad
Hi,
On 2021-07-27 18:40:48 -0400, Tom Lane wrote:
> The first half of that just saves a few hundred bytes of repetitive
> coding. However, I think that the addition of recovery logic is
> important for robustness, because as things stand libpq may be
> worse off than before for OOM handling.
Agr
Andrew Dunstan writes:
> Is it worth making the first one a macro?
It'd be the same from a source-code perspective, but probably a
shade bulkier in terms of object code.
regards, tom lane
On 7/28/21 11:02 AM, Tom Lane wrote:
>
> Here I've got to disagree. We do need the form with a PQExpBuffer
> argument, because there are some places where that isn't a pointer
> to a PGconn's errorMessage. But the large majority of the calls
> are "pqReportOOM(conn)", and I think having to writ
Michael Paquier writes:
> On Tue, Jul 27, 2021 at 10:31:25PM -0400, Tom Lane wrote:
>> Yeah, there are half a dozen places that currently print something
>> more specific than "out of memory". I judged that the value of this
>> was not worth the complexity it'd add to support it in this scheme.
>
On 7/27/21 6:40 PM, Tom Lane wrote:
> While cleaning out dead branches in my git repo, I came across an
> early draft of what eventually became commit ffa2e4670 ("In libpq,
> always append new error messages to conn->errorMessage"). I realized
> that it contained a good idea that had gotten lost
On Tue, Jul 27, 2021 at 10:31:25PM -0400, Tom Lane wrote:
> Yeah, there are half a dozen places that currently print something
> more specific than "out of memory". I judged that the value of this
> was not worth the complexity it'd add to support it in this scheme.
> Different opinions welcome of
"Bossart, Nathan" writes:
> - appendPQExpBuffer(&conn->errorMessage,
> - libpq_gettext("out of
> memory allocating GSSAPI buffer (%d)\n"),
> - payloadlen);
> +
On 7/27/21, 3:41 PM, "Tom Lane" wrote:
> The first half of that just saves a few hundred bytes of repetitive
> coding. However, I think that the addition of recovery logic is
> important for robustness, because as things stand libpq may be
> worse off than before for OOM handling. Before ffa2e46
While cleaning out dead branches in my git repo, I came across an
early draft of what eventually became commit ffa2e4670 ("In libpq,
always append new error messages to conn->errorMessage"). I realized
that it contained a good idea that had gotten lost on the way to that
commit. Namely, let's red
20 matches
Mail list logo
