Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier <pelletier.michel@gmail.com>

View thread
From: Michel Pelletier <pelletier.michel@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2024-11-19T17:50:29Z
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.

>
>
> So going back on the assumption I'm somehow not returning the right
> pointer, but digging into the array code I'm pretty sure I'm following the
> same pattern and tracing my code path is calling EOHPGetRWDatum when I
> return the object, I can't get it to stop on DeleteExpandedObject, so I
> don't think plpgsql is deleting it, I'm going to keep investigating, sorry
> for the noise.
>

A couple years ago I tried to compress what I learned about expanded
objects into a dummy extension that just provides the necessary
boilerplate.  It wasn't great but a start:

https://github.com/michelp/pgexpanded

Pavel Stehule indicated this might be a good example to put into contrib:

https://www.postgresql.org/message-id/CAFj8pRDnAnsm8pMosEys-TDRZpnCx1KaxePjV8HT6A1JPQtsCw@mail.gmail.com

I've updated the repo to include points from our current discussion wrt
multiple expansions in a plpgsql function, and added some test functions.
The new pgexpanded type just keeps track of the number of times it's been
expanded starting from an initialized value.  While it only stores a
flattened integer, it follows the typical pattern of pallocing the value
and pfreeing it with a memory context callback, so it should be covering
most of the boilerplate needed to start a new expanded type.

This would also be a good place to showcase and test the support function
feature you've described to me.

It occurs to me that including this example in contrib would be an easier
way for us to collaborate on my existing issue instead of punting back and
forth on the list and would benefit all future expanded object developers.
Do you think that's a good idea?  If this were in contrib you could access
the code I'm working with directly and I can just follow along in my
project.

-Michel