Accidentally left the doc patch out of the hstore patch posted
previously, so here it is as a separate patch.
--
Andrew (irc:RhodiumToad)
hstore-doc-20090914.patch.gz
Description: hstore doc patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Latest hstore patch with provision for inplace upgrading.
--
Andrew (irc:RhodiumToad)
hstore-20090914.patch.gz
Description: hstore patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Ron == Ron Mayer rm...@cheapcomplexdevices.com writes:
At this point it's been 12 days since this was written and no
updated patch has been posted, so I think it's well past time to
move this to Returned with Feedback. Accordingly I'm going to
make that change. Hopefully, an updated
Robert Haas wrote:
On Wed, Jul 22, 2009 at 2:17 PM, Andrew
Gierthand...@tao11.riddles.org.uk wrote:
Unless I hear any objections I will proceed accordingly...
At this point it's been 12 days since this was written and no updated
patch has been posted, so I think it's well past time to move
Ron Mayer wrote:
Robert Haas wrote:
On Wed, Jul 22, 2009 at 2:17 PM, Andrew
Gierthand...@tao11.riddles.org.uk wrote:
Unless I hear any objections I will proceed accordingly...
At this point it's been 12 days since this was written and no updated
patch has been posted, so I think it's
Bruce Momjian wrote:
Tom Lane wrote:
Perhaps an appropriate thing to do is separate out the representation
change from the other new features, and apply just the latter for now.
Or maybe we should think about having two versions of hstore. This
is all tied up in the problem of having a
Bruce Momjian wrote:
I can just have pg_migrator detect hstore and require it be removed
before upgrading; we did that already for 8.3 to 8.4 and I am assuming
we will continue to have cases there pg_migrator just will not work.
The more things you exclude the less useful the tool
Andrew Dunstan wrote:
I can't imagine losing a huge percentage of pg_migrator users via hstore
changes, especially since you can migrate hstore manually and still use
pg_migrator.
We could finesse the hstore issues, but we are already blown out of the
water right now by the enum
Bruce Momjian wrote:
Andrew Dunstan wrote:
I can't imagine losing a huge percentage of pg_migrator users via hstore
changes, especially since you can migrate hstore manually and still use
pg_migrator.
We could finesse the hstore issues, but we are already blown out of the
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Perhaps an appropriate thing to do is separate out the representation
change from the other new features, and apply just the latter for now.
Or maybe we should think about having two versions of hstore. This
is all
Tom Lane wrote:
Perhaps an appropriate thing to do is separate out the representation
change from the other new features, and apply just the latter for now.
Or maybe we should think about having two versions of hstore. This
is all tied up in the problem of having a decent module
On Wed, Jul 22, 2009 at 2:17 PM, Andrew
Gierthand...@tao11.riddles.org.uk wrote:
Unless I hear any objections I will proceed accordingly...
At this point it's been 12 days since this was written and no updated
patch has been posted, so I think it's well past time to move this to
Returned with
On Jul 22, 2009, at 11:17 AM, Andrew Gierth wrote:
To me (A) is looking like the obvious choice (the people smart enough
to be using hstore-new from CVS already can handle the minor pain of
updating the on-disk format).
Unless I hear any objections I will proceed accordingly...
Yes, that
Tom == Tom Lane t...@sss.pgh.pa.us writes:
I'm prepared to give slightly more consideration to option #3:
make the new code read the old format as well as the new one.
Tom If you think you can make that work, it would solve the problem.
I was hoping to do it without changing the new
On Jul 22, 2009, at 8:55 AM, Andrew Gierth wrote:
The other option would be to fix the wasted-space bug in the existing
hstore, and document that stored data must be updated at least once
subsequent to that fix before doing a binary migrate to 8.5.
Given this…
(The pathological case is
Hi,
Le 22 juil. 09 à 02:56, Robert Haas a écrit :
On Tue, Jul 21, 2009 at 7:25 PM, Tom Lanet...@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 Wed, Jul 22, 2009 at 1:40 PM, Dimitri Fontainedfonta...@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 Lanet...@sss.pgh.pa.us wrote:
Or maybe we should think about having two versions of hstore. This
is all tied up in the
David == David E Wheeler da...@kineticode.com writes:
The other option would be to fix the wasted-space bug in the
existing hstore, and document that stored data must be updated at
least once subsequent to that fix before doing a binary migrate to
8.5.
[...]
David Could it be that
Andrew Gierth and...@tao11.riddles.org.uk writes:
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
I took a quick look at this, and have a couple of beefs associated with
upgrade risks.
1. The patch arbitrarily changes the C-code
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Andrew Gierth and...@tao11.riddles.org.uk writes:
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
Tom I took a quick look at this, and have a couple of beefs
Tom associated with
Andrew Gierth and...@tao11.riddles.org.uk writes:
(b) many of the old names are significant collision risks.
What collision risks? PG does not allow loadable libraries to export
their symbols, so I don't see the problem. I recommend just keeping
those things named as they were.
Certainly
On Wed, 2009-07-22 at 01:06 +0100, Andrew Gierth wrote:
I'm prepared to give slightly more consideration to option #3: make
the new code read the old format as well as the new one. I believe
(though I have not yet tested) that it is possible to reliably
distinguish the two with relatively low
Tom == Tom Lane t...@sss.pgh.pa.us writes:
(b) many of the old names are significant collision risks.
Tom What collision risks? PG does not allow loadable libraries to
Tom export their symbols, so I don't see the problem. I recommend
Tom just keeping those things named as they were.
Jeff == Jeff Davis pg...@j-davis.com writes:
I'm prepared to give slightly more consideration to option #3:
make the new code read the old format as well as the new one. I
believe (though I have not yet tested) that it is possible to
reliably distinguish the two with relatively low
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
Running ALTER TABLE foo ALTER COLUMN bar TYPE hstore USING bar || '';
on all of your hstore columns would suffice to ensure that, I believe.
(Subject to testing once I actually have code for it, of course.)
This could/would be included in
On Tue, Jul 21, 2009 at 7:25 PM, Tom Lanet...@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).
A decent module infrastructure is
Andrew Gierth wrote:
The code already has users who are using it for audit-trail stuff
(easily computing the changes between old and new records and storing
only the differences). Perhaps one of the existing users could express
an opinion on this point.
I use it for exactly that purpose
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
--
Andrew (irc:RhodiumToad)
hstore_20090716.patch.gz
Description: hstore patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
28 matches
Mail list logo
