Re: NAMEDATALEN increase because of non-latin languages

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