Re: cast to domain with default collation issue.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: cast to domain with default collation issue.
Date: 2022-05-24 05:33:51
Message-ID: 1432728.1653370431@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Monday, May 23, 2022, jian he <jian(dot)universality(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Durumdara 2022-05-24 06:17:26 Re: Can I start Update row in After Insert trigger function?
Previous Message David G. Johnston 2022-05-24 05:13:38 Re: cast to domain with default collation issue.