Re: RFD: schemas and different kinds of Postgres objects - Mailing list pgsql-hackers

On Wed, 23 Jan 2002, Tom Lane wrote:

> Bill Studenmund <wrstuden@netbsd.org> writes:
> > 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.
>
> Sorry, I don't accept that either-or proposition.  People will expect to
> be able to continue to use 7.3 as they have used Postgres in the past.
> Among other things that will mean being able to add new users to an
> existing installation.  If we say "you can't do much of anything in 7.3
> until you upgrade all your applications to schema-awareness", then we're
> going to have lots of unhappy users.

"upgrad[ing] .. to schema-awareness" is adding the PATHs to the schema
creates. You then have a unified namespace (to the apps perspective). The
migration tool I mentioned should be able to do this (and will need to be
present).

As PostgreSQL changes, people are going to have to learn to deal with new
features. I really don't think that dealing with schemas is going to be
that hard. Also, at Zembu, all of the apps we looked at had maybe two or
three schemas. These are big apps. If they can live with just a few
schemas, why do we need so many that maintainance is a pain?

Also, what is this new user going to do *IN THE EXISTING APP*? Either the
user is going to change existing tables, for which adding the user to the
ACLs (or better yet to a group) will work, or the new user is going to own
new tables. If the new user is owning new tables, then you have to change
the app to refer to them. If the upgrade to 7.3 included a, "quick
tutorial about the new schema support," the author should be able to adapt
easily.

> >> 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?
>
> Public gives you a place to put the ACL determining what people can do
> with publicly-visible names.  See, eg, comments from Joe Conway.
> Without a specific public namespace to put ACLs on, a dbadmin has very
> little control over interuser interactions.  Please note that the
> facility we are talking about offering here is not available in existing
> Postgres nor in SQL92, but that doesn't make it evil or unreasonable.

I think the existance of a DEFAULT schema (which is a real schema, not a
special namespace) would also aleviate the above concerns.

> Basically my point here is that the SQL spec is not the be-all and
> end-all of database development.  (Have you read C. J. Date's commentary
> on it, for example?)  We have a proven useful concept of object ownership
> in existing Postgres, and I see no need to remove that facility in
> pursuit of slavish adherence to a specification.  If it were a project
> goal to rip out everything in Postgres that is not mentioned in the
> SQL spec, we could have a much smaller distribution ... with lots fewer
> users.

I haven't read the comentary, do you have a URL?

I agree that we should not limit ourselves to SQL'99. But doing more than
SQL'99 is different from wanting to support SQL schemas while using a
different ownership model, when one of the main things of SQL schemas as I
understand it is the ownership model.

Take care,

Bill