Re: NAMEDATALEN increase because of non-latin languages

On Mon, Jul 18, 2022 at 9:58 AM Andres Freund <andres(at)anarazel(dot)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