Re: How to pass around collation information

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

In response to

Responses

Browse pgsql-hackers by date

  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