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:
> > Why not? What's wrong with either schema.foo.function (==>
> > function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
>
> Neither is wrong in isolation, but how do you tell the difference?
> More to the point, given input x.y.z, how do you tell which component
> is what?

See below.

> > Tables and functions can't have the same names as schemas,
>
> News to me. Where is that written on stone tablets? Even if that's

I'm still trying to find the quote, but I found it a few months ago. I'm
looking in SQL99, which is 1100+ pages for section 2. :-)

> considered an acceptable limitation from a purely functional point of
> view, I don't like using it to disambiguate input. The error messages
> you'll get from incorrect input to an implementation that depends on
> that to disambiguate cases will not be very helpful.

?? Depends on how we do it. As I see it, we have four cases. In the
x.y.z.p.q, we have:

1) No table name, but a function name. It's a function call.

2) A table name, but no function name. It's a table reference.

3) Both a table name & function name, and the function is first. I think
this case is an error (I don't think we support function.foo ==
function(foo))

4) Both a table name & function name, and the table is first. This is
foo.function.

Ok, there is a fifth case, no function nor table names, which is an error.

> > Actually functions do have to be schema local. It's in the spec (don't
> > have exactly where with me).
>
> (A) I don't believe that; please cite chapter and verse; (B) even if

Peter got to that one first.

> SQL92 thinks that's okay, we can't do it that way because of
> backwards-compatibility issues.

Why do backwards-compatability issues keep us from doing it?

Yes, I understand we have apps now with different users owning things
(tables, functions) which they all can access, just like they were in one
unified name space. With real schemas, they are in differen namespaces.
But as long as the routines, tables, triggers & such in each schema can
find things in the other schemas as if they were in one namespace, where
is the problem? We just have the app gain PATH directives to path in all
the other schemas.

The app runs, even though there are different schemas involved. Where is
the problem?

> > My vote would be to make them schema-specific. As Peter pointed out,
> > schemas are how you own things,
>
> Sorry, but this line of argument is trying to assume the very point in
> dispute.

When you started this thread, you said you were thinking about
"implementing SQL schemas." Are these "SQL schemas" going to follow the
spec or not? SQL'99 is rather clear that ownership happens at the schema
level. Peter spent quite a lot of time last October pounding that into my
head, and after I looked at the spec, I found he was 100% correct.

If these schemas are to follow the standards, ownership happens at the
schema level. If ownership happens elsewhere, whatever we're doing is not
following the standard. Unfortunatly it's that cut & dried. So why should
we call them "SQL schemas" if we aren't following the SQL spec?

Take care,

Bill