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

From Andres Freund
Subject Re: NAMEDATALEN increase because of non-latin languages
Date
Msg-id 20220623141658.runlcgvlxjioqsjc@alap3.anarazel.de
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
Re: NAMEDATALEN increase because of non-latin languages
List pgsql-hackers
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.


> This would require:
> 
> - changing star expansion in SELECTs (expandRTE etc)
> - adjusting pg_dump, \d, etc
> 
> That much seems clear and agreed upon.

FWIW, I don't agree that this is a reasonable way to tackle changing
NAMEDATALEN. It'd be nice to have, but it to me it seems a pretty small
fraction of the problem of making Names variable length. You'll still have all
the problems of name fields being accessed all over, but now not being
included in the part of the struct visible to C etc.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Use fadvise in wal replay
Next
From: Robert Haas
Date:
Subject: Re: NAMEDATALEN increase because of non-latin languages