Martijn van Oosterhout napsal(a):
> On Tue, Jul 08, 2008 at 09:05:11PM +0200, Zdenek Kotala wrote:
>>> All the argument here is based on the premise that we should have
>>> database-level collation specifications, which AFAICS is not required
>>> nor suggested by the SQL spec.
>> Yeah, it is not required, but by my opinion it should be derived from
>> CREATE SCHEMA statement. There is following item:
>> --- SQL ANSI 2003 page 520 ---
>> 5) If <schema character set specification> is not specified, then a <schema
> Careful, this is a 'character set specification" which has (almost)
> nothing to do with collation. It's closer to the encoding field, which
> is already in pg_database.
Yeah, I'm confuse why for character set is defined behavior when is not
specified but there is not definition how to handle it for collation.
Maybe because charset has default collation.
> The issue with having a "default database collation" is that it's
> unclear where it would be used. In the end the collation is defined by
> the types and domains. Columns inherit from the types. I think the only
> senseible definition is to decide that all the text/varchar/char types
> inherit from the database. It's not in the spec but I think it does
> make easier to decide what the default collation is. As an alternative
> ALTER TYPE text SET DEFAULT COLLATION TO foo;
> <repeat for all other text types>
It is good point I thought about following situation
select 'xxx' < 'yyy';
But how you mentioned because both are text and text type has default collation
there is no reason to have collation per database.
Hmm, It seems to me that expectation should be create all string data types with
default collation during initdb phase. It means modify BKI types definition
according to default locale setting.
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2008-07-09 14:09:35|
|Subject: CREATE CAST too strict?|
|Previous:||From: Marko Kreen||Date: 2008-07-09 12:15:47|
|Subject: Re: Auto-explain patch|