On Mon, Mar 28, 2005 at 10:54:16AM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > Maybe it would work if we forced indexes on shared relations to be
> > scanned using a fixed collation.
>
> The shared relations only have indexes on name, oid, and integer:
> select distinct atttypid::regtype
> from pg_class c join pg_attribute a on c.oid = a.attrelid
> where relisshared and relkind = 'i';
> and name has non-locale-sensitive ordering rules anyway. So that's
> not the big problem; we could probably get away with decreeing that
> name will always be that way and that shared relations can't have
> locale-dependent indexes.
This is good news.
> The big problem (and the reason why this idea has been shot down in
> the past) is that CREATE DATABASE can't change the locale from what it
> is in the template database unless it's prepared to reindex any locale-
> sensitive indexes in the non-shared part of the template database.
> Which would be a difficult undertaking seeing that we can't even connect
> to the copied database until after commit.
I don't see how this is a showstopper. At creation time we may decree
that the database is "incomplete", and users can't normally connect to
it; we only allow that after a phase of correcting minor issues, such as
reindexing if necessary. I recall Fabien Coelho wanted to do something
on this area too.
We could do this with a new column (say) datready in pg_database, set to
false by CreateDb(); at connection time this could be checked. The
downside I see to this is that the bit has to be checked at each
connection start; not sure if this is exceedingly onerous.
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Licensee shall have no right to use the Licensed Software
for productive or commercial use. (Licencia de StarOffice 6.0 beta)
