From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to pass around collation information |
Date: | 2010-05-28 21:18:54 |
Message-ID: | 4C00333E.6000106@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28/05/10 23:15, Robert Haas wrote:
> On Fri, May 28, 2010 at 3:20 PM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
>> On fre, 2010-05-28 at 15:03 -0400, Robert Haas wrote:
>>> I think we need to think of the comparison operators as ternary, and
>>> the COLLATE syntax applied to columns or present in queries as various
>>> ways of setting defaults or explicit overrides for what the third
>>> argument will end up being.
>>
>> How could this extend to things like isalpha() or upper() that would
>> need access to ctype information?
>
> Good question. :-(
Strictly speaking, collation and ctype are two different things. Which
is a convenient way to evade the question :-).
But you could ask, how would we handle more fine-grained ctype in
upper() then? Perhaps by adding a second argument for ctype. Similarly
to to_tsvector([config, ] string), you could explicitly pass the ctype
as an argument, or leave it out in which case a default is used. It
wouldn't give you per-column ctype, though.
What does the spec have to say about the ctype used for upper() et al BTW?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2010-05-28 21:22:37 | Re: List traffic |
Previous Message | Heikki Linnakangas | 2010-05-28 20:49:13 | Re: Failback with log shipping |