On 11/4/22 19:46, Tom Lane wrote:
> Jan Wieck <jan@wi3ck.info> writes:
>> I need to do some testing on this. I seem to recall that the naming was
>> originally done because a reference cursor is basically a named cursor
>> that can be handed around between functions and even the top SQL level
>> of the application. For the latter to work the application needs to know
>> the name of the portal.
>
> Right. With this patch, it'd be necessary to hand back the actual
> portal name (by returning the refcursor value), or else manually
> set the refcursor value before OPEN to preserve the previous behavior.
> But as far as I saw, all our documentation examples show handing back
> the portal name, so I'm hoping most people do it like that already.
I was mostly concerned that we may unintentionally break underdocumented
behavior that was originally implemented on purpose. As long as everyone
is aware that this is breaking backwards compatibility in the way it
does, that's fine.
In this case I see current behaviors little bit unhappy. It breaks any recursive call, it can break variable shadowing, so I prefer change. The possibility of compatibility break is clean, but there is an possibility of easy fix, and I think I can detect some possibly not compatible usage in plpgsql_check.
The dependency on current behavior can be probably just for pretty old application that doesn't use refcursors.
Regards
Pavel
>
>> I am currently down with Covid and have trouble focusing. But I hope to
>> get to it some time next week.
>
> Get well soon!
Thanks, Jan