Dear Tom,
> > However, I feel that the owner should own the "public" schema and maybe
> > some other stuff to be carefully selected, without bluring that important
> > distinction?
>
> From a definitional standpoint I don't have a problem with that.
Good.
> From an implementation standpoint, I fear it would be much more trouble
> than it is worth.
What is worth is having a sound tool with as few "little" surprises as
possible. There are a lot of little surprises in pg. None of them worth
the trouble, but collectively, this would make pg adoption easier. I've
some time for this kind of small scale fix, but as this is not the main
agenda here around, and it is very difficult to pass even small things.
> You can't easily connect to another database.
That's what I derived from browsing the source code.
> Possibly it would work to have this housekeeping done in the first
> backend to connect to the new database, but I don't think it could be
> done directly by CREATE DATABASE.
Well, this describe basically my feeling about the implementation.
If I have some time I may send a proof of concept implementation.
I though of the following lines:
- in createdb, add a some "todo" file into the new database directory
with the set of sql commands to be executed on the first connection.
- on a connection in postgres backend,
(1) check for this todo file
(2) if it exists,
lock something appropriate [or could be directly in (1)?]
if the file [still] exists,
execute these commands as a super user
remove the file
unlock
(3) back to normal processing
This approach would it make easy to change/update the housekeeping
updates if necessary.
The set of appropriate sql commands in still to be discussed...
Another heavier but more general approach would be to add a boolean to
pg_database to tell whether the first connection housekeeping was
performed, and maybe to maintain the set of queries to be executed in
another system table, so that it could be updated by modules that would
need it. This would be some kind of sql-hook for database creation events.
I'm rather inclined to try the former option;-)
--
Fabien Coelho - [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
