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

Bill Studenmund <wrstuden@netbsd.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.

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

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.
        regards, tom lane