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 CAFBsxsGQjEeMg5Sayghj-qnGOVSt6=NQHQ-xadChUvGtHBiFng@mail.gmail.com
Whole thread Raw
In response to Re: NAMEDATALEN increase because of non-latin languages  (Andres Freund <andres@anarazel.de>)
Responses Re: NAMEDATALEN increase because of non-latin languages
List pgsql-hackers
On Thu, Jun 23, 2022 at 9:17 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2022-06-03 13:28:16 +0700, John Naylor wrote:
> > 1. That would require putting the name physically closer to the end of
> > the column list. To make this less annoying for users, we'd need to
> > separate physical order from display order (at least/at first only for
> > system catalogs).
>
> FWIW, it's not at all clear to me that this would be required. If I were to
> tackle this I'd look at breaking up the mirroring of C structs to catalog
> struct layout, by having genbki (or such) generate functions to map to/from
> tuple layout. It'll be an annoying amount of changes, but feasible, I think.

Hmm, I must have misunderstood this aspect. In my mind I was thinking
that if a varlen attribute were at the end, these functions would make
it easier to access them quickly. But from this and the follow-on
responses, these would be used to access varlen attributes wherever
they may be. I'll take a look at the current uses of GETSTRUCT().

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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Michael Paquier
Date:
Subject: Re: amcheck is using a wrong macro to check compressed-ness