út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier < pelletier.mic...@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-tdrzpncx1kaxepjv8ht6a1jpqt...@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 >
