Re: Per-database/schema settings

> > I've done a little work on enabling session-specific default behavior
> > for transaction isolation level.
> Is this the START TRANSACTION [ ISOLATION LEVEL ] command?

afaict, SQL99 calls it

SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...;

> > I'm thinking about how to extend this to default "database-specific"
> > behaviors which persist between sessions (such as "DateStyle",
> > character encoding, etc), perhaps using the ALTER SCHEMA command from
> > SQL99. btw,
> What about something like ALTER DATABASE ... SET DEFAULT foo TO bar; The
> ALTER SCHEMA command should be reserved to schema alerations.

afaik character collation is a "schema" property, but it has been quite
a while since I've looked. If my recollection is true, then there is a
pretty big grey area between "database" and "schema" imho.

> > My initial thought was to add columns to pg_database for each setting,
> > but this is not very extensible.
> If it's an attribute of a database, then it should be a pg_database
> column. Notice how the language I chose virtually forces you to do
> that. :) And what's so non-extensible about that?

Any time a new attribute needs to be set, a new column needs to be
added, requiring a dump/initdb/reload. It would be pretty neat to be
able to execute arbitrary code during database startup, which could
set/unset global variables and ?? I guess that was what I was asking
about.

> What kind of settings are you talking about, besides default character set
> and date style? I would assume that the default charset is the one to be
> used by the NCHAR type?

Transaction isolation level is one. And presumably several other things
we haven't yet thought through.

> About datestyle, I had thought that this setting
> should really be deprecated, with the arrival of the to_char() family. If
> you like a default datestyle, then you can define a view based on
> to_char().

Even if we agree that various *output* date styles are not useful, the
DateStyle setting also affects the interpretation of input date/time
(e.g. month/day or day/month conventions). istm that a lot of apps do
need some flexibility in date/time inputs.
                      - Thomas