Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR - Mailing list pgsql-hackers

From Dent John
Subject Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR
Date
Msg-id 2C39C44A-11B1-47A9-AF0D-5E0DCFEC4F1B@QQdd.eu
Whole thread Raw
In response to Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR  (Dent John <denty@QQdd.eu>)
Responses Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR  (Dent John <denty@QQdd.eu>)
List pgsql-hackers
> On 11 Jan 2020, at 12:04, Dent John <denty@QQdd.eu> wrote:
>
>> On 10 Jan 2020, at 15:45, Daniel Verite <daniel@manitou-mail.org> wrote:
>>
>> 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.
>
> Okay. That’s pretty bad, isn’t it.

I’ve addressed the issue, which was due to me allocating the TupleDesc in the multi_call_memory_ctx, which seemed quite
reasonable,but it actually needs to be in ecxt_per_query_memory. It seems tSRF-mode queries are much more sensitive to
themisstep. 

A v4 patch is attached, which also renames UNNEST(REFCURSOR) to ROWS_IN(REFCURSOR), adds a test case for use in tSRF
mode,and makes some minor fixes to the support function. 

I have not yet made steps towards documentation, nor yet rebased, so the Makefile chunk will probably still fail.

denty.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line
Next
From: David Fetter
Date:
Subject: Re: longs where uint64s could be