Re: namespaces, was Package support for Postgres - Mailing list pgsql-hackers

From Bill Studenmund
Subject Re: namespaces, was Package support for Postgres
Date
Msg-id Pine.NEB.4.33.0110140443000.20774-200000@vespasia.home-net.internetconnect.net
Whole thread Raw
In response to Re: Package support for Postgres  (Bill Studenmund <wrstuden@netbsd.org>)
List pgsql-hackers
On Sat, 13 Oct 2001, Bill Studenmund wrote:

> On Sat, 13 Oct 2001, Tom Lane wrote:
>
> > I also wonder how the fixed, single-level namespace search path you
> > describe interacts with the SQL rules for schema search.  (I don't
> > actually know what those rules are offhand; haven't yet read the schema
> > parts of the spec in any detail...)
>
> Should be independent. The searching only happens when you are not in the
> "standard" package, and you give just a function name for a function.
> The searching would only happen in the current schems. If
> you give a schema name, then I'd expect PG to look in that schema, in
> standard, for that function. If you give both a schema and package name,
> then PG would look in that package in that schema.

My description of namespaces seems to have caused a fair bit of confusion.
Let me try again.

The ability of the package changes to automatically check standard when
you give an ambiguous function name while in a package context is a
convenience for the procedure author. Nothing more.

It means that when you want to use one of the built in functions
(date_part, abs, floor, sqrt etc.) you don't have to prefix it with
"standard.". You can just say date_part(), abs(), floor(), sqrt(), etc.
The only time you need to prefix a call with "standard." is if you want to
exclude any so-named routines in your own package.

I've attached a copy of a package I wrote as part of testing package
initializers and package global variables. It is an adaptation of the
Random package described in Chapter 8 of _Oracle8 PL/SQL Programming_ by
Scott Urman. Other than adapting it to PostgreSQL, I also tweaked the
RandMax routine to give a flat probability.

Note the use of date_part() in the BODY AS section, and the use of rand()
in randmax(). Both of these uses are the ambiguous sort of function naming
which can trigger the multiple searching. Since they are in plpgsql code,
they get parsed in the context of the random package. So when each of them
gets parsed, parse_func first looks in the random package. For rand(), it
will find the rand() function and use it. But for date_part(), since there
isn't a date_part function in the package, we use the one in standard.

If we didn't have this ability, one of the two calls would need to have
had an explicit package with it. There are two choices (either "standard."
would be needed for date_part(), or "random." for rand()), but I think
both would lead to problems. Either choice makes the syntax heavy, for
little gain. Also, if we scatter the package name throughout the package,
if we ever want to change it, we have more occurences to change.

Does that make more sense?

Take care,

Bill

pgsql-hackers by date:

Previous
From: Bill Studenmund
Date:
Subject: Re: schema support, was Package support for Postgres
Next
From: Bill Studenmund
Date:
Subject: Re: Package support for Postgres