Re: Using Expanded Objects other than Arrays from plpgsql - Mailing list pgsql-hackers

From Michel Pelletier
Subject Re: Using Expanded Objects other than Arrays from plpgsql
Date
Msg-id CACxu=vJNMj1MqqUiwATuazoewireaN=7nskD5V-CBEcrs_K6Vg@mail.gmail.com
Whole thread Raw
In response to Re: Using Expanded Objects other than Arrays from plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Nov 19, 2024 at 11:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
> pelletier.michel@gmail.com> napsal:
>> 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:

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

Yeah.  I think we've largely adopted the position that contrib should
contain installable modules that do something potentially useful to
end-users.  A pure skeleton wouldn't be that, but if it's fleshed out
enough to be test code for some core features then src/test/modules
could be a reasonable home.

Great!  I'll put a patch together that adds the skeleton object to src/test/modules and I'll write some expected tests that run the expansion through its paces, when the support function feature happens I'll update it to include tests for that.

Should I include Tom's patch changes on top of mine or keep those separate?  I'm not entirely clear on the best practice to carry those forward as well.

-Michel

 

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Statistics Import and Export
Next
From: Robert Haas
Date:
Subject: Re: Interrupts vs signals