Re: NAMEDATALEN increase because of non-latin languages

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Денис Романенко <deromanenko(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: NAMEDATALEN increase because of non-latin languages
Date: 2021-08-18 16:57:35
Message-ID: aaf2f1f9-5604-49dd-2b2f-8f641fa50a8c@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 8/18/21 12:39 PM, Alvaro Herrera wrote:
> On 2021-Aug-18, Tom Lane wrote:
>
>> 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.)
> Yeah, my impression is that the project of just changing star expansion
> is much, much easier than splitting out attribute identity from physical
> location. The former, as I recall, is a localized change in expandRTE
> and friends, and you don't have to touch anything else. The other part
> of the change is much more invasive and got me into territory that I
> wasn't able to navigate successfully.
>
> (I think we should consider keeping 'attnum' as the display-order
> attribute, and have the physical-and-identity attribute get a new name,
> say attphysnum. That's so that you don't have to change psql and the
> whole world -- the change is transparent to them. This means we need a
> first step that's very invasive, because every single current use of
> 'attnum' has to be changed to attphysnum first, followed by a functional
> patch that changes a few of those back to attnum. It'd be a large
> inconvenience to backend developers to ease the lives of client-side
> developers.)

Can we call it attid just in case we decide some day to break the nexus
on the other side?

I like the idea of keeping it to the catalog to start with.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message alvherre@alvh.no-ip.org 2021-08-18 17:04:11 Re: archive status ".ready" files may be created too early
Previous Message Alvaro Herrera 2021-08-18 16:39:23 Re: NAMEDATALEN increase because of non-latin languages