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