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.