Re: revised hstore patch
От | Robert Haas |
---|---|
Тема | Re: revised hstore patch |
Дата | |
Msg-id | 603c8f070907221045s55cc4f5axf0126ba8078b7365@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: revised hstore patch (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
On Wed, Jul 22, 2009 at 1:40 PM, Dimitri Fontaine<dfontaine@hi-media.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@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. This would have been a good time to start a new thread with a different subject line. ...Robert
В списке pgsql-hackers по дате отправления: