From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Constraint Type Coercion issue? |
Date: | 2005-09-15 02:42:36 |
Message-ID: | 9254.1126752156@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-09-15 03:04:04 | Re: inverse OR distributive law? |
Previous Message | Alvaro Herrera | 2005-09-15 02:14:23 | Per-table freeze limit proposal |