Re: Constraint Type Coercion issue?

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

In response to

Responses

Browse pgsql-hackers by date

  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