Re: Do we really want to migrate plproxy and citext into PG core distribution?

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Asko Oja <ascoja(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?
Date: 2008-07-28 20:40:26
Message-ID: 20080728204026.GB24856@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 28, 2008 at 03:49:21PM -0400, Tom Lane wrote:
> > I kind of assumed we would do it by implementing the COLLATE clause of
> > the CREATE DOMAIN statement.
>
> But to define such a domain, you'd have to commit to a case-insensitive
> version of a specific collation, no? citext currently means "case
> insensitive version of whatever the database's default collation is".
> This might be worrying over nothing significant, but I'm not
> convinced...

In the version of COLLATE I did you had variations on locales
(asc/desc, case (in)sensetive) which could be selected. So you could
make COLLATE CASE_INSENSITIVE actually just modify the existing
collation.

That said, this is no more of a deal than that text also has a default
collation. You talk about "the database's default collation" but with
proper collation support that statement is meaningless. A database has
no collation, only types, expressions and columns do.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen R. van den Berg 2008-07-28 21:04:21 Re: Protocol 3, Execute, maxrows to return, impact?
Previous Message Gregory Stark 2008-07-28 20:30:13 Re: WITH RECUSIVE patches 0723