Re: RFD: schemas and different kinds of Postgres objects

On Wed, 23 Jan 2002, Tom Lane wrote:

> Bill Studenmund <wrstuden(at)netbsd(dot)org> writes:
> >> No, you're missing the point. Which of x,y,z,p,q is the name we
> >> are going to test to see if it is a table or function?
>
> > No, I'm not. :-) You test enough of them to figure out what case you have.
>
> There could be multiple valid interpretations. When you can't even
> figure out where to start, it's too squishy for me. Code complexity
> isn't really the issue here, it's whether a user can understand what's
> going on.
>
> > Actually, it's not that hard. In foo.funcname, do we support anything
> > AFTER the funcname? I don't think so. If there were a parenthesis, then we
> > have a function call. If it's an operator or something else, we have
> > either a table reference, or a foo.funcname function call. So all we have
> > to do is see if p.q (last two elements) is a schema.function, or of q is a
> > function pathed into our current schema. If yes, we have foo.function. If
> > not, then we have some table reference.
>
> Now wait a sec. What you started out with was the claim
>
> > Why not? What's wrong with either schema.foo.function (==>
> > function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
>
> The issue was not figuring out whether the last component was a function
> name or not, it was to determine what the other components were, and in
> particular whether the function name should be presumed to be qualified
> (by the next-to-last component taken as a schema name) or unqualified.
> That in turns changes your assumptions about which of the components
> further left are table names, schema names, or catalog names.

Then you choose. Choose a search order, and document it. If you are going
to go back into a corner full of so much ambiguity, then document your way
out.

You can make it easier restricting say catalogs and schemas to have
different names, or schemas, tables, and functions can't have the same
name. For this, I'd suggest following Oracle's example. I don't think you
can go too wrong using Oracle's behavior to break ties & ambiguities.

> > ... I don't think working with real
> > schemas will be that hard. So why not just do things right from the
> > begining?
>
> If I thought that SQL's model of ownership == namespace was "right",
> then we probably wouldn't be having this argument. I think the spec
> pretty much sucks in this particular department, and I don't see why
> we should restrict our implementation to support only the spec's
> braindead world view. Especially not when it makes the implementation
> harder, not easier, because we end up needing to add in weird frammishes
> to have some semblance of backwards-compatibility too.

?? What weird fammishes from ownership?

It actually makes things (slightly) simpler. All of the owner fields
disapear from most system tables, because the owner is implied by the
containing schema.

Also, what is braindead about the spec? Yes, it's not what I would choose,
and it's different from what PG does now. But it's just that, different.
Given all of the ACL abilities (if the superuser wants user X to be able
to create objects in table Y of schema Z, s/he makes it so), why does it
matter who owns the object?

> Please give me some good reasons (not "the spec says so") why it's
> a good idea to treat ownership of a namespace as equivalent to ownership
> of the objects in it, and why decoupling the concepts at the
> implementation level isn't a reasonable thing to do.

Can you really give a good reason other than, "I don't like it?"

Absent the existance of specs, it's a matter of choice. Having all of the
ownership happen at the schema level or at the individual item level, it's
six of one, half-dozen of the other.

But there is a spec. A spec that, as far as I can tell, all other
schema-claming DBs follow. So why shouldn't we follow it? Yes, you don't
like it. But is this really supposed to be about personal desires, or
about the resulting DB?

Take care,

Bill