On Mon, Jul 18, 2022 at 9:58 AM Andres Freund <and...@anarazel.de> wrote:
> > 0001 is just boilerplate, same as v1 > > If we were to go for this, I wonder if we should backpatch the cast containing > version of GESTRUCT for less pain backpatching bugfixes. That'd likely require > using a different name for the cast containing one. The new version in this series was meant to be temporary scaffolding, but in the back of my mind I wondered if we should go ahead and keep the simple cast for catalogs that have no varlenas or alignment issues. It sounds like you'd be in favor of that. > > 0003 generates static inline functions that work the same as the current > > GETSTRUCT macro, i.e. just cast to the right pointer and return it. > > It seems likely that inline functions are going to be too large for > this. There's a lot of GESTRUCTs in a lot of files, emitting a copy of the > function every time doesn't seem great. Ok. > > current offset is the previous offset plus the previous type length, plus > > any alignment padding suitable for the current type (there is none here, so > > the alignment aspect is not tested). I'm hoping something like this will be > > sufficient for what's in the current structs, but of course will need > > additional work when expanding those to include pointers to varlen > > attributes. I've not yet inspected the emitted assembly language, but > > regression tests pass. > > Hm. Wouldn't it make sense to just use the normal tuple deforming routines and > then map the results to the structs? I wasn't sure if they'd be suitable for this, but if they are, that'd make this easier and more maintainable. I'll look into it. -- John Naylor EDB: http://www.enterprisedb.com
