Re: Using Expanded Objects other than Arrays from plpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Using Expanded Objects other than Arrays from plpgsql
Date
Msg-id 416464.1738606690@sss.pgh.pa.us
Whole thread Raw
In response to Re: Using Expanded Objects other than Arrays from plpgsql  (Michel Pelletier <pelletier.michel@gmail.com>)
Responses Re: Using Expanded Objects other than Arrays from plpgsql
List pgsql-hackers
Andrey Borodin <x4mmm@yandex-team.ru> writes:
>> On 3 Feb 2025, at 22:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not wedded to that name; do you have a better idea?

> I'd propose something like attached. But feel free to ignore my suggestion: I do not understand context of these
structuremembers. 

Hmm, you're suggesting naming those field members after PL/pgSQL's
specific use of them.  But the intent was that they are generic
workspace for anything that provides a EEOP_PARAM_CALLBACK
callback --- that is, the "param" in the field name refers to the
fact that this is an expression step for some kind of Param, and
not to what PL/pgSQL happens to do with the field.

Admittedly this is all moot unless some other extension starts
using EEOP_PARAM_CALLBACK, and I didn't find any evidence of that
using Debian Code Search.  But I don't want to think of
EEOP_PARAM_CALLBACK as being specifically tied to PL/pgSQL.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Better title output for psql \dt \di etc. commands
Next
From: Masahiko Sawada
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions