From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Using Expanded Objects other than Arrays from plpgsql |
Date: | 2024-11-19 18:44:49 |
Message-ID: | CAFj8pRCd6xcH-AYEyHFdGdU89O9JjZ-v-pyQnOwd9zNJkCEdhQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
pelletier(dot)michel(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Foerster | 2024-11-19 19:08:20 | Re: PostgreSQL 15.9 Update: Partitioned tables with foreign key constraints |
Previous Message | Michel Pelletier | 2024-11-19 17:50:29 | Re: Using Expanded Objects other than Arrays from plpgsql |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-11-19 19:06:35 | Re: UUID v7 |
Previous Message | Nathan Bossart | 2024-11-19 18:29:06 | Re: optimize file transfer in pg_upgrade |