Melanie Plageman writes:
> On postgres built off of master on my mac (sierra), the following is the
> output:
[ scratches head ... ] I get the same results on either Mac or Linux:
regression=# create database u8 encoding utf8 template template0;
CREATE DATABASE
regression=# \c u8
You are now co
>
> I did my test on 9.6.5 (Ubuntu 16.04) with:
>
> CREATE TABLE test_col (
> a text COLLATE "en_CA.utf8",
> b text COLLATE "en_US.utf8"
> );
> INSERT INTO test_col VALUES ('A', 'A');
> SELECT a < (SELECT 'foo'::text COLLATE "en_GB.utf8") FROM test_col;
>
> SQL Error: ERROR: could not det
Melanie Plageman writes:
> In this case, why treat implicit and explicit collation conflicts
> differently?
Um ... because the SQL standard says so?
regards, tom lane
On Fri, Jun 8, 2018 at 9:24 AM, Melanie Plageman
wrote:
> It seems like this would not allow the function/operator to decide if it
> cares about a determinate collation during execution, since it would
> already have errored out during planning.
>
In the case where the function/operator doesn't
> IIRC this was an intentional decision, made on the grounds that we
> can't tell whether the function/operator actually cares about having
> a determinate collation or not, so we have to leave it to execution of
> that function/operator to complain or not.
>
>
In this case, why treat implicit and
On Fri, Jun 8, 2018 at 9:12 AM, Melanie Plageman
wrote:
> I tried inserting data and did not get an error:
>
> CREATE TABLE test1 (
> a text COLLATE "de_DE",
> b text COLLATE "es_ES"
> );
>
> INSERT INTO test1 VALUES('b','b'), ('c','c'), ('g','g'), ('h','h');
> SELECT a < (select 'foo' CO
>
> Data, apparently...I got the same non-error result before inserting a
> record into test1 then I got the expected error.
>
> Its the function/operator the fails when faced with invalid input, not the
> planner, so the error requires data to provoke.
>
> David J.
>
>
>
I tried inserting data an
"David G. Johnston" writes:
> On Thu, Jun 7, 2018 at 4:37 PM, Melanie Plageman
> wrote:
>> I thought this would error out because the subquery's result is considered
>> implicit and, in this case, it seems you now have conflicting implicit
>> collations. However, this does not produce an error. W
On Thu, Jun 7, 2018 at 4:37 PM, Melanie Plageman
wrote:
> CREATE TABLE test1 (
> a text COLLATE "de_DE",
> b text COLLATE "es_ES",
> ...
> );
>
> My thought was to add the following example:
>
> SELECT a < (select 'foo' COLLATE "fr_FR") FROM test1;
>
> I thought this would error out b
You could mark the subquery's result with a collation like this:
>
> postgres=# SELECT 'c' COLLATE "de_DE" > (SELECT 'ç') COLLATE "es_ES";
> ERROR: collation mismatch between explicit collations "de_DE" and "es_ES"
>
> I'm not sure if this behavior is considered a bug, but I also can't imagine
>>
On 05/06/18 07:10, Melanie Plageman wrote:
Hi,
I noticed what seems like a bug in collation.
This query errors out:
SELECT (SELECT 'c' COLLATE "de_DE") > (SELECT 'ç' COLLATE "es_ES"); --
error
While this query does not:
SELECT 'c' COLLATE "de_DE" > (SELECT 'ç' COLLATE "es_ES"); -- no error
I
Hi,
I noticed what seems like a bug in collation.
This query errors out:
SELECT (SELECT 'c' COLLATE "de_DE") > (SELECT 'ç' COLLATE "es_ES"); --
error
While this query does not:
SELECT 'c' COLLATE "de_DE" > (SELECT 'ç' COLLATE "es_ES"); -- no error
It seems like this is in conflict with what th
12 matches
Mail list logo
