Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Monday, 28. July 2008 schrieb Tom Lane:
>> 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".
> So in the future, someone using citext with lc_collate = en_US attempting to
> upgrade would then define
> CREATE DOMAIN citext AS text COLLATION "en_US(at)ci"
> And yes, you would potentially have different definitions of this citext
> domain in different database clusters, depending on what configuration you
> are upgrading from, but I don't see that as a problem. It is the natural
> thing to do.
I'm still not completely convinced that this would be smooth in
practice; for instance there might be situations where you wanted to
define citext but didn't know the target database collation. Still,
I have to concede that it's probably an adequate answer, or at least
close enough that the objection to including citext now doesn't hold up.
It seems that the majority opinion is in favor of including citext
in contrib, so I will go work on that now.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: David E. Wheeler||Date: 2008-07-29 16:09:58|
|Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution? |
|Previous:||From: Gregory Stark||Date: 2008-07-29 15:48:46|
|Subject: Re: Python 2.5 vs the buildfarm|