Re: Constraint Type Coercion issue? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Constraint Type Coercion issue?
Date
Msg-id 9254.1126752156@sss.pgh.pa.us
Whole thread Raw
In response to Re: Constraint Type Coercion issue?  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Constraint Type Coercion issue?
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> Well yes, but given the number of possible locales, creating one class
> for each seems excessive. And each class would have to create 5
> operators (with underlying functions) and 1 comparitor function. Unless
> you could shortcut something like:

> CREATE OPERATOR CLASS ...
>    OPERATOR 1 <(text,text,'en_US')
> ...
>    FUNCTION 1 mycompare(text,text,'en_US')
> ...
>    COLLATE en_us;

The thing that's still fairly unclear to me is whether the collation
information is attached to the operators/functions or to the data.
I recall there's been some discussion of sticking collation IDs into
individual text Datums, which is a completely different path than what
you are positing above.  Does the SQL spec mandate one or the other of
these approaches?  If it does, do we want to believe it?  (The more I
read of SQL2003, the less impressed I get...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Per-table freeze limit proposal
Next
From: Tom Lane
Date:
Subject: Re: inverse OR distributive law?