On Wed, 23 Jan 2002, Tom Lane wrote:
> Bill Studenmund <wrstuden@netbsd.org> writes:
> > One of the things schemas have to support is essentially a PATH specifier.
>
> Yes, but...
>
> > So all we need to do is have all of the schemas created in a new DB have
> > path specifiers pulling in all of the other schemas. Thus we can make a
> > schema-savy system act as if it has only one namespace.
>
> When you create a new user, do all those path specifiers for the
> existing users magically update themselves? Seems like maintenance
> would be a pain.
No, they don't. But why should they? Why should they need to?
Either we're migrating an existing app, for which adding PATH directives
with a helper program before restore works, or we're making a new app. If
you're designing an app for a schema-savy system, you need to think about
schemas.
> Fernando's "any" idea is probably a cleaner way to handle it if we
> wanted to do things like that. But I still think it'll be safer and
> more controllable if we provide a "public" namespace instead; see
> followup discussions.
Why? Why is it needed? What would public let you do that PATH and ACLs
wouldn't?
The only reason I can see it's needed is so that people can make new apps
for a schema-savy PostgreSQL while ignoring the schemas. That strikes me
as bad. I agree that schemas shouldn't interfeer with things, but to let
folks just blow them off seems equally bad.
Also, it wouldn't be SQL'99 schemas. It can still be done, but it's
solving a problem that the other SQL'99 databases don't seem to have.
Take care,
Bill