Re: nchar is undocumented
От | Peter Eisentraut |
---|---|
Тема | Re: nchar is undocumented |
Дата | |
Msg-id | 0924daa4-53e8-40ee-b8a7-73307a8ea34a@eisentraut.org обсуждение исходный текст |
Ответ на | Re: nchar is undocumented (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-docs |
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.
В списке pgsql-docs по дате отправления: