Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Martijn van Oosterhout napsal(a):
>>> Not necessarily. pg_class is not shared yet without it you can't even
>>> find pg_database. Same deal with pg_type. All it means is that
>>> pg_collation in template1 must contain all the collations used in
>>> template1, which shouldn't be hard to arrange.
>
>> I think, Collation situation is different,
>
> 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
character set specification> that specifies an implementation-defined character
set that contains at least every character that is in <SQL language character>
is implicit.
----
It is not for collation directly, but if I understand it correctly when you want
to create schema then default charset is inherit from parent instance which is
database (catalog).
Following sentence specified that pg_collation should be database specific.
---- SQL ANSI 2003 page 15 ---
Character sets defined by standards or by SQL-implementations reside in the
Information Schema (named INFORMATION_SCHEMA) in each catalog, as do collations
defined by standards and collations, transliterations, and transcodings defined
by SQL-implementations.
----
> I wonder why we are allowing a> nonstandard half-measure to drive our thinking, rather than solving the> real problem
whichis column-level collations.
I try to determine how to implement collation itself - collation catalog
structure and content and how to create new collation. Column-level collation is
nice but until we will not have basic infrastructure we cannot start implemented it.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
