Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 7, 2017 at 5:53 AM, Emrul <emrul@emrul.com> wrote:
>> A solution might be to make NAMEDATALEN configurable without having to
>> recompile source (perhaps a config variable or an initdb parameter). When I
>> have some free time I will investigate whether this is doable.
> Well, it wouldn't be free. The problem is:
> typedef struct nameData
> {
> char data[NAMEDATALEN];
> } NameData;
> If it were not a compile-time constant, every bit of code that uses
> NameData (or otherwise depends on NAMEDATALEN being constant) would
> have to be changed. That would be invasive and likely have at least a
> minor performance cost.
It's a lot worse than just the code that accesses the names; if that were
all then we might hope to hide most of the issue underneath macros like
RelationGetRelationName. The problem is that if NameData isn't constant
length, that also breaks the struct overlay mechanism for catalog rows,
introducing notational and performance costs for essentially every catalog
field access in the entire backend. That is, in places like
CATALOG(pg_type,1247) BKI_BOOTSTRAP BKI_ROWTYPE_OID(71) BKI_SCHEMA_MACRO
{ NameData typname; /* type name */ Oid typnamespace; /* OID of namespace containing this type
*/ Oid typowner; /* type owner */ ...
typnamespace and following fields are no longer easily accessible
to C code.
You could partly get around that by relocating name columns to the ends
of their catalog rows --- but only partly, and it would be a darn odd
looking result.
It's interesting to speculate about NameData becoming some sort of short
fixed-length pointer to a variable-length string stored somewhere else
(like the end of the row). But TBH I cannot see a scheme like that ever
getting out of the realm of speculation --- it would break too many
*other* assumptions, many of them in performance-critical places like
tuple assembly and disassembly.
In the end I just don't think this is worth the work it would take to
improve matters significantly over the current situation. It's too much
work benefitting too few people.
regards, tom lane