Re: Trouble with FETCH_COUNT and combined queries in psql - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Trouble with FETCH_COUNT and combined queries in psql
Date
Msg-id c2c16dae-db04-43a2-b0e1-126fc1b6e2eb@manitou-mail.org
Whole thread Raw
In response to Re: Trouble with FETCH_COUNT and combined queries in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Trouble with FETCH_COUNT and combined queries in psql
List pgsql-hackers
    Tom Lane wrote:

> 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.

Looking at the end of the discussion about \cset, it seems what
you were against was not much how the detection was done rather
than how and why it was used thereafter.

In the case of the present bug, we just need to know whether there
are any \; query separators in the command string.
If yes, then SendQuery() doesn't get to use the cursor technique to
avoid any risk with that command string, despite FETCH_COUNT>0.

PFA a simple POC patch implementing this.

> 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.

It would also work with queries that start with a CTE, and queries
like (UPDATE/INSERT/DELETE.. RETURNING), that the current way
with the cursor cannot handle. But that looks like a project for PG13,
whereas a fix like the attached could be backpatched.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: pg_dump partitions can lead to inconsistent state after restore
Next
From: Tom Lane
Date:
Subject: Minor postmaster state machine bugs