Re: RFD: schemas and different kinds of Postgres objects

Bill Studenmund <wrstuden(at)netbsd(dot)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.

>> 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.

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.

regards, tom lane