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 s
> "Ron" == Ron Mayer 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 patch will be r
Ron Mayer wrote:
> Robert Haas wrote:
> > On Wed, Jul 22, 2009 at 2:17 PM, Andrew
> > Gierth 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 tim
Robert Haas wrote:
> On Wed, Jul 22, 2009 at 2:17 PM, Andrew
> Gierth 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 w
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. Th
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
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
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
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 dec
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 infrastruc
On Wed, Jul 22, 2009 at 2:17 PM, Andrew
Gierth 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 Feedback". Accordingly I'm
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 seem
> "David" == "David E Wheeler" 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 only
On Wed, Jul 22, 2009 at 1:40 PM, Dimitri Fontaine wrote:
> Hi,
>
> Le 22 juil. 09 à 02:56, Robert Haas a écrit :
>>
>> On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane wrote:
>>>
>>> Or maybe we should think about having two versions of hstore. This
>>> is all tied up in the problem of having a decent mo
Hi,
Le 22 juil. 09 à 02:56, Robert Haas a écrit :
On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane 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 ind
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 _very
> "Tom" == Tom Lane 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 format, but
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 (a
On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane 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 probably not going to f
* 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
> "Jeff" == Jeff Davis 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 overhead
> "Tom" == Tom Lane 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.
You've nev
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 l
Andrew Gierth 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 when developing this I had _S
> "Tom" == Tom Lane writes:
Tom> Andrew Gierth 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 upgrade risks.
Tom> 1. The patch
Andrew Gierth 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 names of several existing
SQL
26 matches
Mail list logo
