Peter Eisentraut wrote:
> Instead of installing an "extension", that is, say, a collection
> of types and functions provided by a third-party source, I would
> like to have a mechanism to deploy my own actual database
> application code.
On the matter of schemas, I suggest that we consider two ideas that have
helped RPM in its early days, when everyone had their own very specific ideas
about what should be installed where:
- file system hierarchy standard
- relocations
Of course if you have IMPORT from an extension, it's down to the DBA:
INSTALL chinese_calendar;
IMPORT FROM chinese_calendar SECTION (default) INTO SCHEMA pg_extension;
IMPORT FROM chinese_calendar SECTION (year_names) INTO SCHEMA lookups;
INSTALL peter_e_app;
IMPORT FROM peter_e_app SECTION (all) INTO SCHEMA public;
Of course this means two things:
1. Every "extension" has to have its own schema mappings.
2. The application view of the database is a sort of "default extension"
Pros:
- Namespace collisions begone!
- Anything to help extension upgrades could be re-used for applications
(and vice-versa)
- Some stuff isn't visible outside the extension *at all*
- You can separate extension installation from usage (good for
multi-user setups).
Cons:
- Extra layer of indirection (find my namespace => namespace lookup =>
object)
- Extensions need to list what they export in what sections
- More code required
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
