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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
