Re: proposal for PL packages for 8.3. - Mailing list pgsql-hackers
From | Martijn van Oosterhout |
---|---|
Subject | Re: proposal for PL packages for 8.3. |
Date | |
Msg-id | 20060809080250.GC22329@svana.org Whole thread Raw |
In response to | Re: proposal for PL packages for 8.3. (Richard Huxton <dev@archonet.com>) |
Responses |
Re: proposal for PL packages for 8.3.
Re: proposal for PL packages for 8.3. |
List | pgsql-hackers |
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.
pgsql-hackers by date: