Re: proposal for PL packages for 8.3.

On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
> There are three separate issues we seem to be talking about.
>
> 1. Namespaces - visibility or otherwise of objects
> 2. Procedural state - something that looks like a shared variable
> 3. Packaging - installation/dependency handling

Well, it would be nice to have some clarification about the expected
scope and lifetimes of these variables. If two different sessions
change the values, what's supposed to happen?

> Namespaces
> Given that we already have search_path it makes sense to use it. So, we
> could have something like:
> 1. A "PRIVATE" modifier for objects that mean they are only accessible
> if their schema is the first in the search_path.
> 2. A definable search_path for a schema, so all objects have that
> setting by default. In theory, this could break dynamic queries in
> functions that relied on a changeable search_path.

Having a per-function search path has been discussed before, primarily
on the basis that having the search_path affect the results of
functions defined previously is wierd, except you might actually want
this sometimes.

It hasn't been done because its expensive. As long as the search_path
doesn't change, you can cache the results of lookups. Under the current
system, a frequently changing search_path would be bad for performence.

> Procedural state
> Just a convenient way of defining some small amount of state. Will need
> session variables and static shared variables. Presumably we'll need to
> be able to lock shared variables.

Lock? That sounds like a recipe for deadlocks to me. What do people
want to use these variables for anyway?

> Packaging
> I'd guess we'd need a pg_package and pg_package_items system tables. We
> could track:
> - package name (different from schema)
> - version number
> - install/uninstall functions
> - start-session/end-session functions
> - dependencies (is pg_depend enough)
> pg_package_items
> - schema-name
> - variables, functions, tables, views etc

This has been discussed before. In particular, you can probably use the
pg_depends table to track items installed by a package, thus dispensing
with the pg_package_items. The biggest stumbling block was finding
something general enough. Oh yeah, and coding it. In particular,
consider being able to install stuff in contrib as a package, so you
can easily uninstall it.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.