Re: NAMEDATALEN increase because of non-latin languages

Hi,

On 2022-07-18 09:46:44 +0700, John Naylor wrote:
> I've made a small step in this direction.

Thanks for working on this!

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

> 0002 teaches Catalog.pm to export both C attr name and SQL attr name, so we
> can use "sizeof".
> 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.

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

Greetings,

Andres Freund