Re: Using Expanded Objects other than Arrays from plpgsql

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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