Martijn van Oosterhout wrote:
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
Advertising
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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
