Re: cast to domain with default collation issue.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: jian he <jian.universality@gmail.com>,
"pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Date: 2022-05-24T05:33:51Z
Lists: pgsql-general
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, May 23, 2022, jian he <jian.universality@gmail.com> wrote:
>> CREATE DOMAIN testdomain AS text;
>> --asume the default collation is as per show LC_COLLATE;
>> – on my pc, it is C.UTF-8.
>> --So the testdomain will be collation "C.UTF-8"
> My reading of the docs say this is consistent with outcome #2.
> https://www.postgresql.org/docs/current/collation.html
Yeah. The comments in parse_collate.c are clear that this behavior is
intentional:
case T_CoerceToDomain:
{
/*
* If the domain declaration included a non-default COLLATE
* spec, then use that collation as the output collation of
* the coercion. Otherwise allow the input collation to
* bubble up. (The input should be of the domain's base type,
* therefore we don't need to worry about it not being
* collatable when the domain is.)
*/
Perhaps this should be documented more clearly, but it's not obviously
wrong. If the domain declaration doesn't include an explicit COLLATE
then casting to the domain doesn't create an explicit collation
requirement. (That is, the domain *doesn't* have a specific
collation attached to it, any more than type text does.)
regards, tom lane
Commits
-
Doc: clarify the default collation behavior of domains.
- e0047269a8c9 10.22 landed
- d6d9ea0a468b 13.8 landed
- d26ac35d0d7c 15.0 landed
- cc5de7ba255d 12.12 landed
- be35a6456901 14.5 landed
- a8c63282ddce 11.17 landed