Peter Eisentraut wrote:
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an existing database would render
indexes broken.
Perhaps we could've put them in datconfig, and forbidden changing them
after CREATE DATABASE. Then again, encoding is a similar setting too,
and that's stored in a catalog column.
Yeah, it's a tricky case somewhere in between all the facilities that we
already have.
I notice in the documentation that the createdb --lc-ctype sets the
lc_ctype setting for the database, but the corresponding parameter for
CREATE DATABASE is CTYPE, but the global GUC setting is lc_ctype. Should
that be more consistent?
Hmm, I remember I pondered for a long time if it should be COLLATE and
CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
that a) COLLATE/CTYPE looks nicer and b) if we add support for ICU or
some other collation implementation, the association with LC_*
environment variables becomes misleading.
Being consistent would be nice, though.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
