From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Using Expanded Objects other than Arrays from plpgsql |
Date: | 2025-02-03 18:48:56 |
Message-ID: | 419663.1738608536@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
I wrote:
> 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.
However ... given that I failed to find any outside users today,
I'm warming to the idea of "void *paramarg[2]". That does look
less random than two separate fields. There are probably not
any extensions that would need to change their code, and even
if there are, we impose bigger API breaks than this one in
every major release.
So I'm willing to do that if it satisfies your concern.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2025-02-03 19:15:02 | Re: Using Expanded Objects other than Arrays from plpgsql |
Previous Message | Tom Lane | 2025-02-03 18:18:10 | Re: Using Expanded Objects other than Arrays from plpgsql |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-02-03 18:55:52 | Re: Skip collecting decoded changes of already-aborted transactions |
Previous Message | Masahiko Sawada | 2025-02-03 18:41:03 | Re: Skip collecting decoded changes of already-aborted transactions |