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

From Tom Lane
Subject Re: NAMEDATALEN increase because of non-latin languages
Date
Msg-id 1459083.1629303164@sss.pgh.pa.us
Whole thread Raw
In response to Re: NAMEDATALEN increase because of non-latin languages  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: NAMEDATALEN increase because of non-latin languages
Re: NAMEDATALEN increase because of non-latin languages
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 8/18/21 10:53 AM, Tom Lane wrote:
>> Yeah, it would annoy the heck out of me too.  Again there's a potential
>> technical solution, which is to decouple the user-visible column order
>> from the storage order.  However, multiple people have tilted at that
>> windmill without much success, so making it a prerequisite for improving
>> the name-length situation doesn't seem like a smart plan.

> There might be other benefits, though. IIRC what we discussed years ago
> was having for each attribute an immutable number (presumably attnum as
> now) and a mutable display order and storage order. Previous patches
> didn't implement this and so were rejected. I think part of the trouble
> is that we'd have to go through roughly 1700 mentions of attnum in the
> source and decide if it's really attnum they want or if it's
> attnum_display_order or attnum_storage_order. So this has the potential
> to be extraordinarily invasive and potentially bug-prone. And then
> there's the world of extensions to consider.

Yeah, exactly: conceptually that's simple, but flushing all the bugs
out would be a years-long nightmare.  It'd make all the fun we had
with missed attisdropped checks look like a walk in the park.  Unless
somebody can figure out a way to mechanically check for mistakes,
I don't think I want to go there.

I wonder though if we could fix the immediate problem with something
less ambitious.  The hard part of the full proposal, I think, is
separating permanent identity from physical position.  If we were to
split out *only* the display order from that, the patch footprint
ought to be far far smaller --- basically, I think, we'd need to fix
star-expansion and not a lot more in the backend.  Of course,
client-side code like psql's \d and pg_dump would need to be upgraded
too, but any missed things there would be cosmetic that's-not-the-
expected-column-order bugs, not core dumps.  Also, at least in the v1
patch we could use this just for system catalogs without exposing it
as a feature for user tables, which would greatly restrict the set of
client-side places that really need fixed.

(I think Alvaro was the last person to mess with this issue, so I
wonder what his take is on the feasibility of such a restricted
solution.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: NAMEDATALEN increase because of non-latin languages
Next
From: Peter Geoghegan
Date:
Subject: Re: The Free Space Map: Problems and Opportunities