Re: psql FETCH_COUNT feature does not work with combined queries

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Fabien Coelho <postgresql(dot)org(at)coelho(dot)net>
Subject: Re: psql FETCH_COUNT feature does not work with combined queries
Date: 2020-07-16 23:44:47
Message-ID: CAKFQuwaRMxxBbCbf23L09+Stu0zcpJQeaS-FYN6Zzm848WvM4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 16, 2020 at 4:24 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> On 2020-Jul-16, David Johnston wrote:
>
> > Instead of a note maybe add a paragraph stating:
> >
> > "This setting is ignored when multiple statements are sent to the server
> as a single command (i.e., via the -c command line option or the \;
> meta-command). Additionally, it is possible for certain combinations of
> statements sent in that manner to instead return no results, or even be
> ignored, instead of returning the result set of the last query. In short,
> when FETCH_COUNT is non-zero, and you send a multi-statement command to the
> server, the results are undefined. This combination in presently allowed
> for backward compatibility."
>
> I personally dislike documenting things that don't work, if worded in a
> way that don't leave open the possibility of fixing it in the future.
> So I didn't like Fabien's original wording either, though I was thinking
> that just adding "This may change in a future release of Postgres" might
> have been enough. That seems more difficult with your proposed wording,
> but maybe you see a good way to do it?
>
> After rereading it a few times, I think it's too specific about how it
> fails. Maybe it's possible to reduce to just the last two phrases,
> along the lines of
>
> > When FETCH_COUNT is non-zero, and you send a multi-statement command
> > to the server (for example via -c or the \; meta-command), the results
> > are undefined. This combination in presently allowed for backward
> > compatibility and may be changed in a future release.
>
>
Everything may change in a future release so I am generally opposed to
including that. But I'm ok with being less descriptive on the observed
failure modes and sweeping it all under "undefined". Need to fix my typo,
"This combination is presently allowed".

When FETCH_COUNT is non-zero, and you send a multi-statement command
to the server (for example via -c or the \; meta-command), the results
are undefined. This combination is presently allowed for backward
compatibility.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2020-07-16 23:47:14 Re: Wrong results from in_range() tests with infinite offset
Previous Message David Johnston 2020-07-16 23:33:23 Re: [DOC] Document concurrent index builds waiting on each other