From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: updated hstore patch |
Date: | 2009-09-20 13:21:38 |
Message-ID: | 4AB62C62.5030109@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Gierth wrote:
> I'd appreciate public feedback on:
> - whether conversions to/from a {key,val,key,val,...} array are needed
> (and if there's strong opinions in favour of making them casts; in the
> absence of strong support for that, I'll stick to functions)
Strikes me as an independent separate patch. It seems totally
orthogonal to the features in the patch as submitted, no?
> - what to do when installing the new version's .sql into an existing db;
> the send/recv support and some of the index support doesn't get installed
> if the hstore type and opclasses already exist. In the case of an upgrade
> (or a dump/restore from an earlier version) it would be nice to make all
> the functionality available; but there's no CREATE OR REPLACE for types
> or operator classes.
It seems similar in ways to the PostGIS upgrade issues when their
types and operators change:
http://postgis.refractions.net/docs/ch02.html#upgrading
It seems they've settled on a script which processes the dump file
to exclude the parts that would conflict?
If the perfect solution is too complex, I'd also kinda hope this isn't a
show-stopper for this patch, but rather a TODO for the future modules feature.
> If there are any more potential showstoppers I'd appreciate hearing about
> them now rather than later.
From | Date | Subject | |
---|---|---|---|
Next Message | Abhijit Menon-Sen | 2009-09-20 14:50:11 | Re: GRANT ON ALL IN schema |
Previous Message | Dimitri Fontaine | 2009-09-20 12:31:46 | Re: Anonymous code blocks |