Re: updated hstore patch

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.

In response to

Responses

Browse pgsql-hackers by date

  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