Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michel Pelletier <pelletier.michel@gmail.com>
Cc: pgsql-general <pgsql-general@lists.postgresql.org>
Date: 2024-10-20T19:19:00Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow extension functions to participate in in-place updates.

  2. Implement new optimization rule for updates of expanded variables.

  3. Detect whether plpgsql assignment targets are "local" variables.

  4. Preliminary refactoring of plpgsql expression construction.

  5. Refactor pl_funcs.c to provide a usage-independent tree walker.

  6. Generalize plpgsql's heuristic for importing expanded objects.

Michel Pelletier <pelletier.michel@gmail.com> writes:
> On Sun, Oct 20, 2024 at 10:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The other problem is that plpgsql only knows how to do such expansion
>> for arrays, and it's not obvious how to extend that part.

> Perhaps a third member function for ExpandedObjectMethods that formalizes
> the expansion interface like found in DatumGetExpandedArray?  I closely
> follow that same pattern in my code.

The trouble is we don't have an expanded object to consult at this
point --- only a flat Datum.  plpgsql has hard-wired knowledge that
it's okay to apply expand_array if the datatype passes the typisarray
tests, but I'm pretty unclear on how to provide similar knowledge for
extension datatypes.

			regards, tom lane