Skip site navigation (1) Skip section navigation (2)

Re: revised hstore patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: revised hstore patch
Date: 2009-07-22 17:45:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
>  - 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:
>> 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.


In response to

pgsql-hackers by date

Next:From: Andrew GierthDate: 2009-07-22 18:17:49
Subject: Re: revised hstore patch
Previous:From: Dimitri FontaineDate: 2009-07-22 17:40:29
Subject: Re: revised hstore patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group