Re: Conflict of implicit collations doesn't propagate out of subqueries

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

In response to

Responses

Browse pgsql-hackers by date

  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