Re: Trouble with FETCH_COUNT and combined queries in psql
От | Fabien COELHO |
---|---|
Тема | Re: Trouble with FETCH_COUNT and combined queries in psql |
Дата | |
Msg-id | alpine.DEB.2.21.1904221928050.29102@lancre обсуждение исходный текст |
Ответ на | Trouble with FETCH_COUNT and combined queries in psql ("Daniel Verite" <daniel@manitou-mail.org>) |
Ответы |
Re: Trouble with FETCH_COUNT and combined queries in psql
|
Список | 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 по дате отправления: