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 858F7EC2-4BEE-4871-96AE-AB3A8BA5B113@QQdd.eu
Whole thread Raw
In response to Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR
Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR
List pgsql-hackers
> On 10 Jan 2020, at 15:45, Daniel Verite <daniel@manitou-mail.org> wrote:
>
> At a quick glance, I don't see it called in the select-list  in any
> of the regression tests. […]

Yep. I didn’t test it because I figured it wasn’t particularly useful in that context. I’ll add some tests for that too
onceI get to the root of the problem. 

> 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.

It’s crashing when it’s checking that the returned tuple matches the declared return type in rsinfo->setDesc. Seems
rsinfo->setDescgets overwritten. So I think I have a memory management problem. 

To be honest, I wasn’t fully sure I’d got a clear understanding of what is in what memory context, but things seemed to
workso I figured it was close. Seems I was wrong. I need a bit of time to review. Leave it with me, but I guess it’ll
taketo next weekend before I get more time. 

denty.


pgsql-hackers by date:

Previous
From: Artur Zakirov
Date:
Subject: Re: Add pg_file_sync() to adminpack
Next
From: Julien Rouhaud
Date:
Subject: Re: Avoid full GIN index scan when possible