Re: NAMEDATALEN increase because of non-latin languages

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: NAMEDATALEN increase because of non-latin languages
Дата
Msg-id 20220623141658.runlcgvlxjioqsjc@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: NAMEDATALEN increase because of non-latin languages  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: NAMEDATALEN increase because of non-latin languages  (Robert Haas <robertmhaas@gmail.com>)
Re: NAMEDATALEN increase because of non-latin languages  (John Naylor <john.naylor@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Use fadvise in wal replay
Следующее
От: Robert Haas
Дата:
Сообщение: Re: NAMEDATALEN increase because of non-latin languages