Re: search_path vs extensions

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Subject: Re: search_path vs extensions
Date: 2009-05-29 15:05:47
Message-ID: 7A7B01EC-9E90-4138-BD8F-47D7ACC3FD2B@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Le 29 mai 09 à 16:11, Andrew Dunstan a écrit :
> I think almost all these difficulties could be overcome if we had
> some sort of aliasing support, so that arbitrary objects in schema a
> could be aliased in schema b. If that were in place, best practice
> would undoubtedly be for each module to install in its own schema,
> and for the DBA to alias what is appropriate to their usage scenario.

This coupled with Peter's idea of nested namespace seems a killer
feature for me. That means the pg_extension namespace isn't a flat
mess but a organized one, with private (internal) objects deeper into
the hierarchy. It makes it easy to have a top-level schema per
extension without rendering search_path impracticable.

Then you slice atop of if aliasing so that you can refer to
pg_extension.a.part1.obj_x from say utils.a.x or even utils.x, DBA
choice. Or simply alias schema pg_extension.a.part1 as a. Whatever.

It seems to offer the best of both worlds: we know where extensions
are meant to end up getting installed (private (nested) sub schema(s)
in pg_extension), and DBA has the option to mask this implementation
detail by aliasing it all wherever needed, with a choice of granularity.

> But unless someone wants to tackle that I think we should leave
> schema management entirely alone, and leave it up to the extension
> author / DBA between them.

Well, we all know that proper extension/module/plugin packaging
system, flexible for both authors and users, reliable and built for
next 20 years... it won't be made in a breathe. If some expected it to
be easy, I think it's time to revise the plans. Want to have it all in
8.5? Still time to join ;)

If the way to have good extension packaging support in PostgreSQL
means we need aliasing first (which I think is called synonym in the
standard), let's work on this as a first step patch?
In theory, it's even possible to begin work on extensions without
synonyms/alias, using the pg_extension forced place (but with nested
namespace support) and have the alias be done in parallel or after, as
soon as we know what we want the big picture to look like when
finished. Incremental work, etc.

Regards,
--
dim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2009-05-29 15:05:59 Re: PostgreSQL Developer meeting minutes up
Previous Message Andrew Dunstan 2009-05-29 14:41:53 Re: Python 3.0 does not work with PL/Python