Hi,
The same mail as before in a new thread, per Robert comment. Including
the body rather than an archive link for various reasons, including
making it easy to comment here rather than there.
Le 22 juil. 09 à 02:56, Robert Haas a écrit :
On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Or maybe we should think about having two versions of hstore. This
is all tied up in the problem of having a decent module
infrastructure
(which I hope somebody is working on for 8.5).
I indeed still intend to provide some patch in the 8.5 cycle. While
the user design issue didn't receive any push back, some big items
remain to be solved. So here's my current TODO about it:
- get some more familiar and involved in backend code by being one of
the RRR
- consider the proposed syntax ok for a first stab at it
- make the pg_catalog.pg_extension entry and the associated commands
with version as text, one thing at a time please
- bootstrap core components in pg_extension for dependancy on them
(plpgsql, ...)
- implement a backend function pg_execute_commands_from_file('path/to/
file.sql');
reserved to superuser, file in usual accepted places
- implement INSTALL EXTENSION with the previous function
- adding a static backend local variable installing_extension (oid)
- modifying each SQL object create statement to add entries in
pg_depend
- add an specific type for handling version numbers and operators
comparing them
Here are from memory the problems we don't have a solution for yet:
- how to give user the ability to install the extension's objects in
another schema than the pg_extension default one
- how to provide extension author a way to have major PG version
dependant code without having to implement and maintain a specific
function in their install.sql file
Please go comment on this other thread if you think the syntax is
awful or for helping me through the big tickets:
http://archives.postgresql.org/pgsql-hackers/2009-06/msg01281.php
A decent module infrastructure is probably not going to fix this
problem unless it links with -ldwiw. There are really only two
options here:
I beg to defer. The way for a decent *extension* facility to handle
the case is by providing an upgrade function which accepts too
arguments: old and new version of the module. Then the module author
is able to run custom code from within the module upgrade transaction,
where migrating on disk data representation is entirely possible.
pg_depend would have to allow for easy finding of a given datatype
column I guess.
(I am also not aware that anyone is working on the module
infrastructure problem, though of course that doesn't mean that no-one
is; but the point is that's neither here nor there as respects the
present problem. The module infrastructure is just a management layer
around the same underlying issues.)
Of course if anyone wants to join, I'd appreciate. Some have offered
help and I've been failing to provide them with my todo list... but
getting a first patch for next commit fest is a goal.
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
