From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Dent John" <denty(at)QQdd(dot)eu> |
Cc: | "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>,"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>,"Roman Pekar" <roma(dot)pekar(at)gmail(dot)com> |
Subject: | Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR |
Date: | 2020-01-10 15:45:15 |
Message-ID: | cc290a0c-e24c-45a8-a704-6120c2433f4c@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dent John wrote:
> Yes. That’s at least true if unnest(x) is used in the FROM. If it’s used in
> the SELECT, actually it can get the performance benefit right away
At a quick glance, I don't see it called in the select-list in any
of the regression tests. When trying it, it appears to crash (segfault):
postgres=# begin;
BEGIN
postgres=# declare c cursor for select oid::int as i, relname::text as r from
pg_class;
DECLARE CURSOR
postgres=# select unnest('c'::refcursor);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The build is configured with:
./configure --enable-debug --with-icu --with-perl --enable-depend
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2020-01-10 16:36:48 | Re: Avoid full GIN index scan when possible |
Previous Message | Tom Lane | 2020-01-10 15:31:30 | Re: Avoid full GIN index scan when possible |