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

Re: revised hstore patch

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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:40:29
Message-ID: CD935014-0AB9-4E0F-9457-8101480F3D41@hi-media.com (view raw or flat)
Thread:
Lists: 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(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.

Regards,
-- 
dim

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-07-22 17:45:50
Subject: Re: revised hstore patch
Previous:From: Tom LaneDate: 2009-07-22 17:03:49
Subject: Re: change do_tup_output to take Datum arguments rather than cstring

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