From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Markus Winand <markus(dot)winand(at)winand(dot)at> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Conflict of implicit collations doesn't propagate out of subqueries |
Date: | 2020-05-28 21:43:44 |
Message-ID: | 8137.1590702224@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Markus Winand <markus(dot)winand(at)winand(dot)at> writes:
> However, if the conflict happens in a subquery, it doesn’t anymore:
> WITH data (c, posix) AS (
> values ('a' COLLATE "C", 'b' COLLATE "POSIX")
> )
> SELECT *
> FROM (SELECT *, c || posix AS none FROM data) data
> ORDER BY none || posix;
> c | posix | none
> ---+-------+------
> a | b | ab
> (1 row)
I'm not exactly convinced this is a bug. Can you cite chapter and verse
in the spec to justify throwing an error?
AIUI, collation conflicts can only occur within a single expression, and
this is not that. Moreover, even if data.none arguably has no collation,
treating it from outside the sub-query as having collation strength "none"
seems to me to be similar to our policy of promoting unknown-type subquery
outputs to type "text" rather than leaving them to cause trouble later.
It's not pedantically correct, but nobody liked the old behavior.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2020-05-28 21:59:52 | Re: speed up unicode normalization quick check |
Previous Message | Mark Dilger | 2020-05-28 21:24:17 | Re: Expand the use of check_canonical_path() for more GUCs |