Re: revised hstore patch

On Wed, Jul 22, 2009 at 1:40 PM, Dimitri Fontaine<dfontaine(at)hi-media(dot)com> wrote:
> Hi,
>
> Le 22 juil. 09 à 02:56, Robert Haas a écrit :
>>
>> On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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.

This would have been a good time to start a new thread with a
different subject line.

...Robert