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
