Tom Lane wrote:
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > Why do we have to have system tables per *database* ?
> > Is there anything wrong with global system tables ?
> > And how about adding dbid to pg_class,pg_proc etc ?
>
> We could, but I think I'd vote against it on two grounds:
>
> 1. Reliability. If something corrupts pg_class, do you want to
> lose your whole installation, or just one database?
>
> 2. Increased locking overhead/loss of concurrency. Currently, there
> is very little lock contention between backends running in different
> databases. A shared pg_class will be a single point of locking (as
> well as a single point of failure) for the whole installation.
Isn't current design of PG's *database* for dropdb using "rm -rf"
rather than for above 1.2. ?
If we couldn't rely on our db itself and our locking mechanism is
poor,we could start different postmasters for different *database*s.
> It would solve the DROP DATABASE problem kind of nicely, but really
> it'd just be downgrading DROP DATABASE to a DROP SCHEMA operation...
>
What is our *DATABASE* ?
Is it clear to all people ?
At least it's a vague concept for me.
Could you please tell me what kind of objects are our *DATABASE*
objects but could not be schema objects ?
Regards.
Hiroshi Inoue