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