Re: proposal for PL packages for 8.3. - Mailing list pgsql-hackers

Martijn van Oosterhout wrote:
> On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
> 
>> 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.

That's why I was thinking per-schema. It would mean multiple caches of 
course, but unless you have a pathological number of schemas it should 
be efficient enough.

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

I'd like session vars such as applicaton_user, application_session_id 
etc. You can work around this with pl-tcl/perl functions and/or temp 
tables at the moment, but it would be more convenient to use a variable.

However, if we allow variables that are visible outside a single backend 
then they'll need the usual concurrency controls - at least some way to 
atomically read-and-update. Now, it might be that we can just use a 
table to back up shared variables (store a text representation of their 
value) in which case we get good known semantics for free.

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

Just what I was thinking - if most of contrib can't easily be put into 
packages then the package isn't useful enough.

--   Richard Huxton  Archonet Ltd