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:
> > 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?
>
> > ?? 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.
>
> 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? And which
> of these names is a schema name --- if you don't even know that,
> it's hard to argue that checking to see if some name is known is
> a well-defined operation.

No, I'm not. :-) You test enough of them to figure out what case you have.
Yes, it might be a bit of work, but it's doable.

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.

> > 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?
>
> If you use only the SQL-defined operations, after setting up any
> configuration variables we may invent in the way we will document as
> necessary for SQL-compatible behavior, then you will get SQL-compatible
> behavior. I do not think that precludes having an underlying
> implementation that sees the world differently than SQL does and
> supports non-SQL behaviors too. (For that matter, I'm sure there is
> text somewhere in the spec that points out that the spec intends to
> define user-visible behavior, not implementation.)

While I agree in principle, that quote is from talking about ownership. I
don't see how we can gloss over ownership. :-)

Also, why support two different behaviors? That means 1) there's code
bloat since the backend has to support both. 2) Support is harder as major
DB behaviors will change depending on these settings. 3) I still haven't
seen anything this variant behavior would do that can't be done with
schema paths and access control lists, other than it would let people keep
thinking about things as they do now.

That latter reason doesn't strike me as a good one. Yes, it will take some
getting used to to wrap minds around schemas, but once done, I don't think
it will be that hard. Yes, the documentation will need work, and the
tutorial will need changing (And Bruce will need to release a new edition
of his book :-) , but once that's done, I don't think working with real
schemas will be that hard. So why not just do things right from the
begining?

Take care,

Bill