On 8/18/21 10:53 AM, Tom Lane wrote:
> Julien Rouhaud <rjuju123@gmail.com> writes:
>> On Wed, Aug 18, 2021 at 10:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I wonder if we'd get complaints from changing the catalog column layouts
>>> that much. People are used to the name at the front, I think. OTOH,
>>> I expected a lot of bleating about the OID column becoming frontmost,
>>> but there hasn't been much.
>> I don't think that would be comparable. Having an extra oid in the
>> 1st column doesn't really make a raw SELECT * harder to read. But
>> having the XXXname column way behind, and not even at the end, means
>> that most people will have to type an extra "xxxname," for each
>> throwaway query run to quickly verify something. I know that I often
>> do that, and while I could live with it I'd rather not have to do it.
> 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.
I have a bit less sympathy for the argument that just moving it will
break things that use 'select *' on the catalogs. In general, if you
care about the order of columns you should name the columns you want in
the order you want. I've seen 'select *' break for people on other
changes, like adding or dropping a column. It might cause Postgres
developers a bit of pain, but it should be manageable, so I kind of like
your suggestion.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
