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
to:
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.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
