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

From Fabien COELHO
Subject Re: Trouble with FETCH_COUNT and combined queries in psql
Date
Msg-id alpine.DEB.2.21.1904221928050.29102@lancre
Whole thread Raw
In response to Trouble with FETCH_COUNT and combined queries in psql  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: Trouble with FETCH_COUNT and combined queries in psql
List pgsql-hackers
Bonjour Daniel,

> When FETCH_COUNT is set, queries combined in a single request don't work
> as expected:
>
> \set FETCH_COUNT 10
> select pg_sleep(2) \; select 1;
>
> No result is displayed, the pg_sleep(2) is not run, and no error
> is shown. That's disconcerting.

Indeed.

> Does anyone have thoughts about how to fix this?

> ATM I don't see a plausible fix that does not involve the parser
> to store the information that it's a multiple-query command and pass
> it down somehow to is_select_command().

The lexer (not parser) is called by psql to know where the query stops 
(i.e. waiting for ";"), so it could indeed know whether there are several 
queries.

I added some stuff to extract embedded "\;" for pgbench "\cset", which has 
been removed though, but it is easy to add back a detection of "\;", and 
also to detect select. If the position of the last select is known, the 
cursor can be declared in the right place, which would also solve the 
problem.

> Or a more modern approach could be to give up on the cursor-based method 
> in favor of PQsetSingleRowMode().

Hmmm. I'm not sure that row count is available under this mode? ISTM that 
the FETCH_COUNT stuff should really batch fetching result by this amount.
I'm not sure of the 1 by 1 row approach.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: block-level incremental backup
Next
From: Robert Haas
Date:
Subject: Re: block-level incremental backup