Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnRki-007MSK-2H for pgsql-docs@arkaria.postgresql.org; Wed, 04 Feb 2026 01:32:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vnRkf-008Ntg-1Q for pgsql-docs@arkaria.postgresql.org; Wed, 04 Feb 2026 01:32:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnRkf-008NtY-0Y for pgsql-docs@lists.postgresql.org; Wed, 04 Feb 2026 01:32:17 +0000 Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vnRkc-00000000wnJ-3Kam for pgsql-docs@lists.postgresql.org; Wed, 04 Feb 2026 01:32:16 +0000 Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-45effa36240so4559866b6e.1 for ; Tue, 03 Feb 2026 17:32:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770168733; cv=none; d=google.com; s=arc-20240605; b=dQuJ1NPkoKBslExHSbxIcwT6cOsbXGXrBIKze/GVwcf9wcoT+PjSPvStL9dyV64P6X 0sTqOOJEfrRHlgkmh5ZbPZx1BUup2T4fNBAvgINhGg11BmIXJqbIOg917IgdK9Mh8zfm y7xjHAcGfDJcxJ5fjQuFQDrA31Lat/VnsbJoe1Gcxg39lLZumj8XQKmkNgkgJoA0/qED w2oihjhXasXKcSEgaaz4tH4opwt9tZQKN8l8Zv3On42rYIAhi/lPP4mOVTbb71ELOs5L M6sd1RnwDXXq8pZUvl+X0jywGbs3Ie6efnPb/enklKi8AafNTBPsdnQ8tC6Z5eEu1Hsx JdEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kngvV4We9s8XKYZHVNtI0ZIV/6Z/GwuSAUyKe5iyLVQ=; fh=zit2fdUqiH84Uym3ffkplhUSQkhH5r6DXoFzXld5QmY=; b=Lq8xW46ftbXll5t8goSJOvZB5Ywfg0PQy7rimM1qmsityxd064TKyfGnYlOMICxMxk RBPUqgzkRgpFUZPH1kzHfAQZcs/+xQSpqKyzwKiowKPRklRMqIyAZb+sPYFlPlyGIDmS mQQZAi51DAGA7bTGcgDpUzUu3BkJ9yUjz8dg3FHc7LYlbWXmc/OX4BAneanOBvzBSZcW xvQgieyGw3QbdZbqyT6o1fIWmlqEFLcdotX6x7P4zm27E6K0MiLpsjcyD1UYqCDxaypp UYFyWPw8rQDjb4sLh6agtpY8kYH09Ndva1TVLFJQolnaVOM7oD0D4LJjV3McaWSeD6cL LxyA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770168733; x=1770773533; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kngvV4We9s8XKYZHVNtI0ZIV/6Z/GwuSAUyKe5iyLVQ=; b=CcgmGG5HkEG/6l+NyeJp7bL3RwaQxTCqZR7ZRe+MSwHFS9uuFcVQ+cgpkG+yD70w9E PuXK7n+cI0rRYGCz0PTB48B20yPu5OUPDJSKhUEcN9DTeAdVcpD3TP+huBr2Nbx/3c0l SliKrPsXTozomxg8MTCqc4ox5ExyBBtmXtDE8bmb+NlRFGgOY1qJMAzygsms4WC1QslQ WZCyr/Bb+JA4c5PPB7W+3peFA2bGIgEe+nfXLVcknW/cHqC5Xt4vKkTiByjdGnb49oNF x4D2juugVQEdxbjmf/ZZFQBiUxFbitJrl2YszgP2yd+YoJI+XMROOkjKt1EesplPZZ3k hvqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770168733; x=1770773533; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kngvV4We9s8XKYZHVNtI0ZIV/6Z/GwuSAUyKe5iyLVQ=; b=wVSczUc74F7K8aehFYirjNcelkvwQ2sqZiZf4pGtw+dYdmwaGoaFXL8kmOvr0tZWIw ccFDlpbmmZM9MuG7mXUdKAEesZAcHaKhpAg5T7GCnncyz12fdYABpuhG10PvRbRmYEfg r16exuHL1/EIe7SirnxxXsFLXokXJjkY5c5J9eiaz6W9VBGoI+wK4EZFneqdHcMn0Nkq kcZygTDd6LytVAsiGGp9OwWk/I64bS8xxMo7fvacU/TXxr6xj52exxkC79k1tNJkrSKq xKLPWjcOxpIg2WP9C/jAc6uJ2QvIekDVBUJOvMocT9wh+NeSTx9qgCngiEysShtJquDg cjtw== X-Forwarded-Encrypted: i=1; AJvYcCUPBdZ2AdRYyKztwUdUhlwY8Z0eAFoo8tL2mqGsctH2zgTGZQLDRFNLTv8bCNjAzCOZg82ACaohQNFN@lists.postgresql.org X-Gm-Message-State: AOJu0Yz4Sw/96yRLD839V6vQrMNFYeBheNnvxe5fvxOLpPkhiEIRo7Hb aBtyyJJ1AQu4wDyRzLQ/nmfhbZoJWJr/5Y8txHobuS9Qw8gQGDAgVvlxowXESuhPgfiPSDCKBh8 Cto/WQHsRX/UrTyUYoGc4rywGEaULqkQ= X-Gm-Gg: AZuq6aJ370NRj4JFueVhkq7ILVbfEwxEoUu4niQUWAEs+9cDYI0id+7e91GMCXFw3Iz 7xWEp0aKtgadhPdLWt5Yw1iT8K9o/gYFbGw+QNcMhYYIneqfe2S6bjyenrqxBaHPf0n4ydnY2KG VVP2hotUIcjeZtI7yRMEmYq7jb6maRx8XUvq0Aocf+qtJguIrxcIYgcLX7i9s5Ob6b9oBGuxgsu jWCiDsT7fTK+TUXwUWIt0Qac5nwiccYkR9asmwFM1/aeuysExXm77V3VqBhNXlCZss+5A7H X-Received: by 2002:a05:6808:130d:b0:45e:9dc3:11ea with SMTP id 5614622812f47-462d59c36d8mr761850b6e.40.1770168732728; Tue, 03 Feb 2026 17:32:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "David G. Johnston" Date: Tue, 3 Feb 2026 18:31:36 -0700 X-Gm-Features: AZwV_QgdPc8UWyURUiwzkRSxqE-OPQ3dhaf4op0d57XqHb2el5bVglAZ6_84Ij4 Message-ID: Subject: Re: [PATCH] docs: document N'...' national character string literal syntax To: Erik Wienhold Cc: Hoda Salim , pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000081c06e0649f5866e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000081c06e0649f5866e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 3, 2026 at 5:24=E2=80=AFPM Erik Wienhold wrote= : > On 2026-02-02 21:04 +0100, Hoda Salim wrote: > > > nchar is an alias of bpchar. There's no cast to char behind the scen= es > > > since that would truncate the string: > I'm seeing things differently: postgres=3D# select '123 '::nchar, '123 '::bpchar; bpchar | bpchar --------+-------- 1 | 123 (1 row) Not a huge fan of the proposed wording but partly because the rest of the section doesn't mention data types at all so this is going to move the bar forward, leaving the others behind. nit: I don't like saying N'...' is equivalent to a data type; something more like N'...' produces a value of type bpchar. Also, any reason not to just say: "This syntax is accepted for compatibility with the SQL standard." and move on? Repeating "uses a single character set/does not implement a separate national character set" seems unnecessary. If there is at least one secondary consideration for accepting this syntax we should state what it is. I'd copy the E'...' wording in the first paragraph: ... just before the opening single quote, e.g., N'foo'. I'd suggest going even further in the emulation by leading with the title of the thing being described, then the syntax. i.e., flip the ordering of the first two sentences and rework for flow. My thought: For compatibility with the SQL standard, PostgreSQL accepts national character string constants. A national character string constant is specified by writing the letter N (upper or lower case) just before the opening single quote, e.g., N'foo'. (When continuing a national character string constant across lines, write N only before the first opening quote.) PostgreSQL's implementation requires that characters comprising the literal be encoded using the database encoding, just like all other string constants. In fact, the concept of national character strings is implemented purely at the SQL syntax layer (including data type names nchar and nchar varying). Within the database, the bpchar and bpchar(n) data types are used. A similar note would be added to Data Types. I'd add after Example 8.1: The SQL standard defines two additional data types pertaining to national character strings. PostgreSQL only accommodates a single, database-wide, character set via its database encoding, and so gains no practical benefit from these distinct data types. However, as a compatibility shim, PostgreSQL does implement SQL syntax to accept the nchar and nchar varying data types. These get mapped onto bpchar and bpchar(n) (and thus character) data types respectively. David J. --00000000000081c06e0649f5866e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 3, 2026 at 5:24=E2=80=AFPM Erik Wienhold <<= a href=3D"mailto:ewie@ewie.name">ewie@ewie.name> wrote:
=
On 2026-02-02 21:04 +0100, Hoda Salim wrote:<= br> > > nchar is an alias of bpchar.=C2=A0 There's no cast to char be= hind the scenes
> > since that would truncate the string:

I'm seeing things differently:

postgres=3D#= select '123 =C2=A0 '::nchar, '123 =C2=A0 '::bpchar;
=C2= =A0bpchar | bpchar
--------+--------
=C2=A01 =C2=A0 =C2=A0 =C2=A0| 1= 23 =C2=A0
(1 row)

Not a huge fan of the propos= ed wording but partly because the rest of the section doesn't mention d= ata types at all so this is going to move the bar forward, leaving the othe= rs behind.

nit: I don't like saying N'...'= is equivalent to a data type; something more like N'...' produces = a value of type bpchar.

Also, any reason not to just s= ay:

"This syntax is accepted for compatibility wi= th the SQL standard."=C2=A0 and move on?=C2=A0 Repeating "uses a = single character set/does not implement a separate national character set&q= uot; seems unnecessary.=C2=A0 If there is at least one secondary considerat= ion for accepting this syntax we should state what it is.

I'd copy the E'...' wording in the first paragraph:
=
... just before the opening single quote, e.g., N'foo'.
= I'd suggest going even further in the emulation by leading with the tit= le of the thing being described, then the syntax.=C2=A0 i.e., flip the orde= ring of the first two sentences and rework for flow.

<= br>
My thought:

For compatibility=C2=A0with th= e SQL standard, PostgreSQL accepts national character string constants.=C2= =A0 A national character string constant is specified by writing the letter= N (upper or lower case) just before the opening single quote, e.g., N'= foo'. (When continuing a national character string constant across line= s, write N only before the first opening quote.)=C2=A0 PostgreSQL's imp= lementation requires that characters comprising the literal be encoded usin= g the database encoding, just like all other string constants.=C2=A0 In fac= t, the concept of national character strings is implemented purely at the S= QL syntax layer (including data type names nchar and nchar varying).=C2=A0 = Within the database, the bpchar and bpchar(n) data types are used.
=
A similar note would be added to Data Types.=C2=A0 I'd add= after Example 8.1:

The SQL standard defines two addit= ional data types pertaining to national character strings. PostgreSQL only = accommodates a single, database-wide, character set via its database encodi= ng, and so gains no practical benefit from these distinct data types.=C2=A0= However, as a compatibility shim, PostgreSQL does implement SQL syntax to = accept the nchar and nchar varying data types.=C2=A0 These get mapped onto = bpchar and bpchar(n) (and thus character) data types respectively.
=
David J.

--00000000000081c06e0649f5866e--