Re: schema support, was Package support for Postgres

(I've been following the thread, at least casually ;)

> Why? Operators are used differently than functions. That strikes me as a
> good reason to namespace them differently.
> 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.

But operators *are* functions underneath the covers. So different
namespacing rules seem like a recipe for missed associations and
unexpected results.

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

> Another take on that is that I expect the main user of (direct) function
> calls calling package functions will be other functions in that package,
> while the main users of operators will be places which have used a type
> from said package. Like queries pulling things out of tables using that
> type. So the function namespacing is a concenience/tool primarily for the
> package developer, while the operator and type namespacing is more a
> convenience for the end application developer.

We are probably drawing too fine a distinction here.

> Also, you seem to be wanting a path-search ability that is something like
> the PATH environment variable. This pathing is fundamentally different; to
> use unix terms, it is ".:..". The fundamental difference is that there are
> no "absolute" paths. The searching is totally location (of routine)
> dependant.
> To add something like an absolute path would totally break the whole
> motivation for packages. The idea is to give a developer an area overwhich
> s/he has total name control, but if s/he needs built-in routines, s/he
> doesn't need to say "standard." to get at them.
> If we allow something like "absolute paths" in the package namespacing,
> then we totally destroy that. Because a package developer can't be sure
> what pathing is going on, s/he really has no clue what packages will get
> found in what order. So then you have to be explicit in the name of all
> the functions you use (otherwise if a user essentially puts something
> other than "." at the head of the path, then you don't get routines in
> your own package), or run the risk of getting all sorts of run-time
> errors. A feature designed to make writing packages easier now makes them
> harder. That strikes me as a step backwards.

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.

> > > There is a built-in schema, "master". It will have a fixed oid, probalby 9
> > > or 11.
> > 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.
                - Thomas