Re: schema support, was Package support for Postgres

On Tue, 23 Oct 2001, Peter Eisentraut wrote:

> Bill Studenmund writes:
>
> > Why? Operators are used differently than functions.
>
> I don't think so. Operators are a syntacticaly convenience for functions.
> That's what they always have been and that's what they should stay.

How does what you say disagree with what I said?

Operators certainly have a lot more structure to them than a function call
does. That's why you give the restriction and join functions, and you hand
them commutation and negation operators. The optimizer uses all of these
tools to make what you want to have happen (adding for instance) happen as
efficiently as possible. It will re-write what you said in a different
manner, if that different manner holds the same intent yet is more
efficient.

> > Conceptually the main determiner of what function you want is the name, at
> > least as far as from what I can tell from talking with all the programmers
> > I know. Yes, we make sure the types match (are part of the primary key),
> > but the name is the main concept. Operators, however, are more
> > intent-based. The '+' operator means I want these two things added
> > together. I don't care so much what types are involved, I want adding to
> > happen. That's a difference of intent. And that's the reason that I think
> > different namespacing rules make sense.
>
> Naive developers all program by "intent". If I invoke a + operator then I
> expect it to add. If I call a sqrt() function then I expect it to
> calculate the square root. If I execute an INSERT statement then I would
> prefer that I did not delete anything. Designing systems to work by
> "intent" can be construed as an aspect of "user-friendliness".
>
> But the more knowledgeable programmer is mildly aware of what's going on
> behind the scenes: Both "+" and "sqrt" are just names for function code
> that may or may not do what you think they do. So this applies to both
> functions and operators.

So I am a "naive" programmer because I mention intent above? That is very
condescending, Peter, and strikes me as inappropriate. Are you really so
out of things to say that you have to resort to condescension?

At what point have you tried to determine how experienced a programmer I
am? You've never asked me for my resume, or what projects I've worked on
before this. Your comments indicate to me that you have not yet tried the
patch I sent in, and if you have, I really doubt you've made packages with
it. So how can you judge? The fact I disagree with you?

Also, in your "naive" vs "more knowledgeable" programmer comparison, you
mention "user-friendliness" in the "naive" part, the "bad" part. Do you
really think that "user-friendliness" is a bad thing? I hope not.

I think that "user-friendliness" is an important part of programming. It
means that your tools or programmatic interfaces have (or lack) an
appropriateness to the task at hand. It's not just for command lines or
GUIs. I've worked with different libraries and programming packages, and I
have experienced the ones where the design and layout make the
library/package useful, and ones where the design and layout get in the
way.

Hmmm... Thining about it, I now think you're right, that we should have a
way to handle pathing. A package author should be able to set the path
used for routines in the package, though.

> > > The built-in schemas is called DEFINITION_SCHEMA.
> >
> > Why is it different from the "DEFAULT" you get when you log into a
> > database which doesn't have a schema whose name matches your username?
>
> Because SQL says so.

Actually I'm not so sure. See the note to Thomas, especially the last
sentance of section 21.1. It seems that if we have an INFORMATION_SCHEMA
which contains all the views in the spec, and our system tables have
the right behaviors, then we are fine.

Actually, the text in section 20.1, "Introduction to Information Schema
and Definition Schema" is more direct:

"The views of the Information Schema are viewed tables defined in terms of
the base tables of the Definition Schema. The only purpose of the
Definition Schema is to provide a data model to support the Information
Schema and to assist understanding. An SQL-implementation need do no more
than simulate the existance of the Definition Schema as viewed through the
Information Schema views."

So if we have INFORMATION_SCHEMA with the right vies in it, we are fine
doing whatever we want.

> > Not necessarily. A user other than the one who owns the schema can add a
> > package to it. It's the same thing as why we keep track of who added a
> > function. :-)
>
> Blech, I meant "you can replace the owner column with the schema column".

That's actually what I thought you said. :-)

I stil think we can't do that, since someone other than the schema owner
can add a package to a schema. :-) Or at least that's the assumption I'm
running on; we allow users other than PGUID to create functions (and
operators and aggregates and types) in the default (whatever it will be
called) schema, so why shouldn't they be allowed to add packages?

Take care,

Bill