Feedback-ID: ie0a040ee:Fastmail
Message-ID: <0924daa4-53e8-40ee-b8a7-73307a8ea34a@eisentraut.org>
Date: Mon, 6 May 2024 11:34:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: nchar is undocumented
To: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 David Rowley <dgrowleyml@gmail.com>
Cc: Erik Wienhold <ewie@ewie.name>, pgsql-docs@lists.postgresql.org
References: <202405060853.t3thj4gr4cpb@alvherre.pgsql>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <202405060853.t3thj4gr4cpb@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/0924daa4-53e8-40ee-b8a7-73307a8ea34a%40eisentraut.org>
Precedence: bulk

On 06.05.24 10:53, Alvaro Herrera wrote:
> On 2024-May-05, David Rowley wrote:
> 
>> On Sun, 5 May 2024 at 12:41, Erik Wienhold <ewie@ewie.name> wrote:
>>> So, I think we should either remove that one nchar instance (because it
>>> doesn't add any real value) or document it properly.  The attached patch
>>> does the latter.
>>
>> It seems easier to do the former, that way we don't need to reconsider
>> Peter's concerns about not having enough confidence that it matches
>> the standard.
>>
>> I've included Alvaro and Peter to see what they think.
> 
> Yeah, I too am inclined to remove it.  This text was initially written
> by Mantrova, Bartunov and Glukhov and posted in [1] without further
> explanation, from where it was copied by Glukhov into [2]; the one I
> committed is a direct derivate from that.  There was no discussion about
> nchar specifically that I can see, and at least I simply failed to
> realize that nchar was not something that we talk about.
> 
> I'll remove it from the list, and backpatch to 16.

Yeah, makes sense to at least undocument it consistently.

> If you, Erik, want to spend some time thinking through the standard
> definition of NCHAR and whether we conform, perhaps we can document it
> more fully.

I think the idea of NCHAR and its variants is that you could sort of 
have two character sets pre-selected: One is the character set set by 
the client (maybe historically ASCII) and the other is one you designate 
as the "national" one.  Since in PostgreSQL, a given session always has 
one character set active, this is trivially true, so I think we can 
leave it like that.