Re: Using Expanded Objects other than Arrays from plpgsql
От | Tom Lane |
---|---|
Тема | Re: Using Expanded Objects other than Arrays from plpgsql |
Дата | |
Msg-id | 416464.1738606690@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Using Expanded Objects other than Arrays from plpgsql (Michel Pelletier <pelletier.michel@gmail.com>) |
Ответы |
Re: Using Expanded Objects other than Arrays from plpgsql
|
Список | 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 по дате отправления: