Re: Trouble with FETCH_COUNT and combined queries in psql

Hello Tom,

> Keep in mind that a large part of the reason why the \cset patch got
> bounced was exactly that its detection of \; was impossibly ugly
> and broken. Don't expect another patch using the same logic to
> get looked on more favorably.

Although I do not claim that my implementation was very good, I must admit
that I'm not sure why there would be an issue if the lexer API is made
aware of the position of embedded \;, if this information is useful for a
feature.

> I'm not really sure how far we should go to try to make this case "work".
> To my mind, use of \; in this way represents an intentional defeat of
> psql's algorithms for deciding where end-of-query is.

I do not understand: the lexer knows where all queries ends, it just does
not say so currently?

> If that ends up in behavior you don't like, ISTM that's your fault not
> psql's.

ISTM that the user is not responsible for non orthogonal features provided
by psql or pgbench (we implemented this great feature, but not in all
cases).

> Having said that, I did like the idea of maybe going over to
> PQsetSingleRowMode instead of using an explicit cursor. That
> would represent a net decrease of cruftiness here, instead of
> layering more cruft on top of what's already a mighty ugly hack.

Possibly, but, without having looked precisely at the implementation, I'm
afraid that it would result in more messages. Maybe I'm wrong. Also, I'm
ensure how returning new pg results for each row (as I understood the mode
from the doc) would interact with \;, i.e. how to know whether the current
query has changed. Maybe all this has simple answer.

> However ... that'd require using PQsendQuery, which means that the
> case at hand with \; would result in a server error rather than
> surprising client-side behavior. Is that an acceptable outcome?

I've sent a patch to replace the existing PQexec by PQsendQuery for a not
directly related feature, see https://commitfest.postgresql.org/23/2096/

--
Fabien.