Re: Constraint Type Coercion issue?
От
Tom Lane
Тема
Re: Constraint Type Coercion issue?
Дата
Msg-id
9254.1126752156@sss.pgh.pa.us
Ответ на
Re: Constraint Type Coercion issue? (Martijn van Oosterhout)
Список
Дерево обсуждения
Constraint Type Coercion issue? Josh Berkus <josh@agliodbs.com>
Re: Constraint Type Coercion issue? Tom Lane <tgl@sss.pgh.pa.us>
Re: Constraint Type Coercion issue? Martijn van Oosterhout <kleptog@svana.org>
Re: Constraint Type Coercion issue? Tom Lane <tgl@sss.pgh.pa.us>
Re: Constraint Type Coercion issue? Martijn van Oosterhout <kleptog@svana.org>
Re: Constraint Type Coercion issue? Tom Lane <tgl@sss.pgh.pa.us>
Re: Constraint Type Coercion issue? Martijn van Oosterhout <kleptog@svana.org>
Martijn van Oosterhout 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 по дате отправления