Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Michel Pelletier <pelletier.michel@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2024-11-19T18:44:49Z
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.

út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
pelletier.michel@gmail.com> napsal:

>
>> 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.
>

another position can be src/test/modules - I think so your example is
"similar" to plsample

Regards

Pavel


>
> -Michel
>