Re: NAMEDATALEN increase because of non-latin languages - Mailing list pgsql-hackers

From John Naylor
Subject Re: NAMEDATALEN increase because of non-latin languages
Date
Msg-id CAFBsxsEdPLY8w8hMqxpW5SYpEcFiiCjWejWz296ffEZPCKYP6g@mail.gmail.com
Whole thread Raw
In response to Re: NAMEDATALEN increase because of non-latin languages  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: NAMEDATALEN increase because of non-latin languages
List pgsql-hackers

I wrote:

> On Mon, Jul 18, 2022 at 9:58 AM Andres Freund <andres@anarazel.de> wrote:
> > 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.

This would seem to have its own problems: heap_deform_tuple writes to passed arrays of datums and bools. The lower level parts like fetchatt and nocachegetattr return datums, so still need some generated boilerplate. Some of these also assume they can write cached offsets on a passed tuple descriptor.

I'm thinking where the first few attributes are fixed length, not null, and (because of AIX) not double-aligned, we can do a single memcpy on multiple columns at once. That will still be a common pattern after namedata is varlen. Otherwise, use helper functions/macros similar to the above but instead of passing a tuple descriptor, use info we have at compile time. 

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Martin Kalcher
Date:
Subject: Re: [PATCH] Introduce array_shuffle() and array_sample()
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns