AW: AW: Unhappy thoughts about pg_dump and objects inhe rited from template1
To me, though, the point of independent databases is that they be
*independent*, and therefore if we keep them I'd vote for mapping them
to the top-level SQL notion (catalog, you said?). Schemas ought to be
substructure within a database.
Yes, that was also "sort of" the bottom line of the lengthy thread, so
I guess we could call it a plan.
Andreas
3. Schemas are what we call databases. They contain tables, views wtc.
Let us not start this all over again. Our database would correspond to a catalog
if we put schemas below our database hierarchy.
The standard requires, that you see all schemas within one catalog in
one user session. We do not see tables in another database,
thus our database is not equivalent to ANSI schemas.
The standard also requires, that you can qualify a tablename with a schema,
like: "myschema".tabname. This will be the most difficult thing for us.
Andreas
Import Notes
Resolved by subject fallback
I agree; it's a pain that one DB misbehaving kills an entire installation.
If that is of concern you need separate postmasters, no way around that,
and imho not a problem at all.
Andreas
Import Notes
Resolved by subject fallback
At 17:10 9/11/00 +0100, Zeugswetter Andreas SB wrote:
3. Schemas are what we call databases. They contain tables, views wtc.
Let us not start this all over again. Our database would correspond to a
catalog
if we put schemas below our database hierarchy.
The standard requires, that you see all schemas within one catalog in
one user session. We do not see tables in another database,
thus our database is not equivalent to ANSI schemas.
We could run around in circles here: you can't define tables in a catalog,
so our database must be a schema...so it seems that our database is part
catalog, part schema. The important question is how can we most efficiently
implement schemas & catalogs, and I assume that implementing multiple
database connections in one backend process would require a lot more work
than putting a schema layer into our current 'databases'.
The standard also requires, that you can qualify a tablename with a schema,
like: "myschema".tabname. This will be the most difficult thing for us.
The way Dec/RDB handled this transition was to have a default schema. ie.
you could 'attach' to a schema as the default schema (which happened by
default, no pun intended). Subsequent table references that were not
qualified by a schema name were assumed to be from this default schema. You
could subsequently attach to another schema and either (a) specify a schema
alias, or (b) override the default schema.
I think you can also use the schema name to qualify tables without an
explict attach (assuming you are in the catalog).
Perhaps '\connect catalog.schema' would open the catalog and make 'schema'
the default schema.
This way, client programs and users suffer the minimum confusion.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/