Message-ID: <35ea9d87b9d1d9715989e00afba1aad75b5b0931.camel@cybertec.at>
Subject: Re: bpchar datatype is  not equal to character(1) data type
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: yanliang lei <msdnchina@163.com>, pgsql-docs@lists.postgresql.org
Date: Tue, 06 Jun 2023 18:45:37 +0200
In-Reply-To: <5ec1dd7b.54a7.188911e35c3.Coremail.msdnchina@163.com>
References: <5ec1dd7b.54a7.188911e35c3.Coremail.msdnchina@163.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/35ea9d87b9d1d9715989e00afba1aad75b5b0931.camel%40cybertec.at>
Precedence: bulk

On Tue, 2023-06-06 at 22:30 +0800, yanliang lei wrote:
> in the documents (https://www.postgresql.org/docs/current/typeconv-query.=
html),there is the following descrition:
> =E2=80=9Cblank-padded char=E2=80=9D, the internal name of the character d=
ata type.
> =3D=3D=3D>>so bpchar datatype is equal to character data type
>=20
> in the documents (https://www.postgresql.org/docs/15/datatype-character.h=
tml),there is the following descrition:
> =C2=A0character without length specifier is equivalent to character(1).
> =3D=3D=3D>>so character data type is equal to character(1) data type
>=20
> Based on the above description, there is a deduction as follows:
> =C2=A0bpchar datatype is equal to character(1) data type
>=20
> but the following test tells us that:=C2=A0 bpchar datatype is=C2=A0 not =
equal to character(1) data type.
> I want to know why? Maybe the document has error?
>
> [...]
>
> postgres=3D# create table xxx3(c1 bpchar,c2 int);
> CREATE TABLE
> postgres=3D# insert into xxx3 values('aaaaa',1);
> INSERT 0 1
> postgres=3D# \d+ xxx3;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Table "public.xxx3"
> =C2=A0Column |=C2=A0 Type=C2=A0 =C2=A0| Collation | Nullable | Default | =
Storage=C2=A0 | Compression | Stats target | Description=C2=A0
> --------+---------+-----------+----------+---------+----------+----------=
---+--------------+-------------
> =C2=A0c1=C2=A0 =C2=A0 =C2=A0| bpchar=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0| extended |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0
> =C2=A0c2=C2=A0 =C2=A0 =C2=A0| integer |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0| plain=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0
> Access method: heap
>=20
> postgres=3D# select * from xxx3; <<<<----please note this result.
> =C2=A0 c1=C2=A0 =C2=A0| c2=C2=A0
> -------+----
> =C2=A0aaaaa |=C2=A0 1
> (1 row)

There is some special case code in "gram.y" that treats column definitions =
of
CHAR or BIT special, since the standard requires that that means a length o=
f 1.
See the following source comment:

/* We have a separate ConstTypename to allow defaulting fixed-length
 * types such as CHAR() and BIT() to an unspecified length.
 * SQL9x requires that these default to a length of one, but this
 * makes no sense for constructs like CHAR 'hi' and BIT '0101',
 * where there is an obvious better choice to make.
 * Note that ConstInterval is not included here since it must
 * be pushed up higher in the rules to accommodate the postfix
 * options (e.g. INTERVAL '1' YEAR). Likewise, we have to handle
 * the generic-type-name case in AexprConst to avoid premature
 * reduce/reduce conflicts against function names.
 */

So the standard demands that behavior for CHAR or BIT, but it does not
define the behavior of "bpchar", so we have no special case code for that.

If you read the documentation carefully, it says that "bpchar is the intern=
al
name of the character data type", but it doesn't say that the behave identi=
cal.
"bpchar" is not even mentioned in
https://www.postgresql.org/docs/current/datatype-character.html ,
so I think it is OK to consider it an internal thing that should not be use=
d
by users directly.  I think that there is no need to document that small
behavior difference.

Yours,
Laurenz Albe