Re: schema support, was Package support for Postgres

On Tue, 23 Oct 2001, Thomas Lockhart wrote:

> (I've been following the thread, at least casually ;)
>
> > 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.
>
> But operators *are* functions underneath the covers. So different
> namespacing rules seem like a recipe for missed associations and
> unexpected results.

Underneath the covers, yes. But "those covers" make the difference in what
I'm thinking of. An operator isn't just one function call, it can be
multiple ones. And not just multiple itterations, but multiple different
ones depending on what the optimizer is doing. That's why you can give an
operator more than just the procedure operator. You also give it a join
proc and a restrict proc, and you tie it in with a commutator, negator,
and two sort operators. When you use an operator, you're specifying an
intent, and all of these parts of an operator's definition help make that
intent happen.

The problem though is that if operators are namespaced the same as
functions, then we destroy one of the benefits of packages - a seperate
namespace for functions.

Can you think of a specific example where this namespacing causes
problems? The functions and aggregates are namespaced off of the
containing schema, but the types and operators aren't. Inside the package,
you have access to everything in the package. In the enclosing schema, you
have immediate access to the types and operators, and can get at the
functions and aggregates by "packname.".

> > Part of it is that I only expect a package to add operators for types it
> > introduced. So to be considering them, you had to have done something that
> > ties in the type in the package. Like you had to make a column in a table
> > using it.
>
> I'd expect schemas/packages to have operators and functions for existing
> types, not just new ones. That is certainly how our extensibility
> features are used; we are extensible in several dimensions (types,
> functions, operators) and they do not all travel together. We can't
> guess at the future intent of a package developer, and placing
> limitations or assumptions about what *must* be in a package just limits
> future (unexpected or suprising) uses.

Please play with the patch and try it.

There is no restriction in the patch that operators (and functions &
aggregates) can only be for types new to the package. You can add
operators for built-in types, and you can even add operators for other
user-specified types too. And pg_dump will make sure that a user-defiend
type used in a package will get dumped before the package.

> The "absolute path" scoping and lookup scheme is defined in SQL99. I'm
> not sure I understand the issue in the last paragraph: you seem to be
> making the point that absolute paths are Bad because package developers
> don't know what those paths might be. But otoh allowing absolute paths
> (and/or embedding them into a package) gives the developer *precise*
> control over what their package calls and what the behaviors are. istm
> that if a package developer needs to specify precisely the resources his
> package requires, then he can do that. And if he wants to leave it
> flexible and determined by scoping and pathing rules, then he can do
> that too.
>
> afaik relative pathing is not specified in the standard, but we might
> want to consider how we would implement that as an extension and whether
> that gives more power to the packager or developer.

I've found the spec, and am still studying it. Though what I've found so
far is a schema search path. My main interest is for the package itself to
be the first thing searched. After that, whatever search path is
appropriate for the schema seems like the right thing to do. So, besides
the fact I think we should do schemas as per the spec, I think using the
schema search path is the right thing to do.

> > > 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?
>
> It may not be. But SQL99 specifies the name.

Actually, the most interesting thing I saw was in the start of chapter 21
(the chapter on the DEFINITION_SCHEMA) at the bottom of section 21.1.

"The specification provides only a model of the base tables that are
required, and does not imply that an SQL-implimentation shall provide the
functionality in the manner described in this clause."

As I understand that, we are free to impliment things as we wish. We just
need to have the pieces/functionality described therein. We *don't* have
to use the names or exact formats used in the spec.

As a concrete example of what I mean, I believe that we are free to
pg_attribute as it is and still comply with section 21.7 ATTRIBUTES base
table. UDT_NAME we impliment with attrelid, ATTRIBUTE_NAME we do with
attname, ORDINAL_POSITION -> attnum, ATTRIBUTE_DEFAULT we do, IS_NULLABLE
-> attnotnull (we twist the sense, but the functionality is there),
ATTRIBUTES_PRIMARY_KEY we agree (to the extent we don't support schemas
or catalogs yet).

The main thing is that we eventually have an INFORMATION_SCHEMA full of
views which turn the system tables into what the standards want.

Take care,

Bill