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 1429734.1629298438@sss.pgh.pa.us
Whole thread Raw
In response to Re: NAMEDATALEN increase because of non-latin languages  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: NAMEDATALEN increase because of non-latin languages  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: replay of CREATE TABLESPACE eats data at wal_level=minimal
Next
From: Jelte Fennema
Date:
Subject: Don't clean up LLVM state when exiting in a bad way