Re: revised hstore patch - Mailing list pgsql-hackers

Hi,

Le 22 juil. 09 à 02:56, Robert Haas a écrit :
> On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane<tgl@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
associatedcommands     with version as text, one thing at a time please - bootstrap core components in pg_extension for
dependancyon 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
statementto 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'sobjects 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