From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Trouble with FETCH_COUNT and combined queries in psql |
Date: | 2019-04-22 17:42:38 |
Message-ID: | alpine.DEB.2.21.1904221928050.29102@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-04-22 17:44:25 | Re: block-level incremental backup |
Previous Message | Andres Freund | 2019-04-22 17:36:44 | Re: block-level incremental backup |