Re: cast to domain with default collation issue.
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Date: 2022-05-25T06:38:24Z
Lists: pgsql-general
Please don’t top-post. On Tuesday, May 24, 2022, jian he <jian.universality@gmail.com> wrote: > > Otherwise, all input expressions must have the same implicit collation >> derivation or the default collation. If any non-default collation is >> present, that is the result of the collation combination. Otherwise, the >> result is the default collation. >> > > I think the above quote part can be used to explain the following > examples. > >> CREATE TABLE test1 ( a text COLLATE "de_DE", b text COLLATE "es_ES", c >> text ); >> SELECT a < 'foo' FROM test1; > > SELECT c < 'foo' FROM test1; > > But the *non-default* seems not that correct for me. Like a column if it does not mention anything, then the default value is null. So > * create table test111( a tex*t) The default collation for column a is the same as the output of *show lc_collate*. > > so there is no *non-default? * > > I’m not following the point you are trying to make. table111.a contributes the default collation for any expression needing a collation implicitly resolved. David J.
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