> "Bruce" == Bruce Momjian writes:
>> There's still the issue of how to get the improved module
>> definition (new functions etc) into a migrated database. That's
>> not specific to hstore in any way though, it would affect any
>> contrib module that had added stuff in a new release.
B
"David E. Wheeler" writes:
> On Oct 2, 2009, at 10:04 AM, Alvaro Herrera wrote:
>> Yes, that's my point too, against David's argument that "surely someone
>> must have solved it". What we have here is a new problem, so it's not
>> so clear that there's any solution at all (yet).
>
> Yeah, I didn'
David E. Wheeler wrote:
> On Oct 2, 2009, at 11:14 AM, Bruce Momjian wrote:
>
> > Well, if it is just changed syntax, we could wack around the system
> > catalogs. If storage changes, we have to dump/reload that data type.
>
> Andrew solved this problem for hstore by making the new version able
On Oct 2, 2009, at 11:14 AM, Bruce Momjian wrote:
Well, if it is just changed syntax, we could wack around the system
catalogs. If storage changes, we have to dump/reload that data type.
Andrew solved this problem for hstore by making the new version able
to read the old representation. It
David E. Wheeler wrote:
> On Oct 2, 2009, at 9:43 AM, Alvaro Herrera wrote:
>
> >> Plus lots of stuff on pgFoundry. It's a problem that needs to be
> >> solved. Surely someone, somewhere, has solved this problem, no?
> >
> > Dump & reload?
>
> Hahahahaha. No, really. "Dump & reload" is a phrase t
On Oct 2, 2009, at 10:04 AM, Alvaro Herrera wrote:
The point is it's *not* solved in the context of using pg_migrator.
Yes, that's my point too, against David's argument that "surely
someone
must have solved it". What we have here is a new problem, so it's not
so clear that there's any sol
Tom Lane wrote:
> Alvaro Herrera writes:
> > David E. Wheeler wrote:
> >> Plus lots of stuff on pgFoundry. It's a problem that needs to be
> >> solved. Surely someone, somewhere, has solved this problem, no?
>
> > Dump & reload?
>
> The point is it's *not* solved in the context of using pg_migra
Alvaro Herrera writes:
> David E. Wheeler wrote:
>> Plus lots of stuff on pgFoundry. It's a problem that needs to be
>> solved. Surely someone, somewhere, has solved this problem, no?
> Dump & reload?
The point is it's *not* solved in the context of using pg_migrator.
re
On Oct 2, 2009, at 9:43 AM, Alvaro Herrera wrote:
Plus lots of stuff on pgFoundry. It's a problem that needs to be
solved. Surely someone, somewhere, has solved this problem, no?
Dump & reload?
Hahahahaha. No, really. "Dump & reload" is a phrase that end users
will not put up with for much
David E. Wheeler wrote:
> Plus lots of stuff on pgFoundry. It's a problem that needs to be
> solved. Surely someone, somewhere, has solved this problem, no?
Dump & reload?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom D
On Oct 2, 2009, at 8:20 AM, Bruce Momjian wrote:
Most modules just install functions, which are easily
uninstalled/reinstalled. A data type like hstore is more complicated
assuming it is the data type that is changing and not the support
functions.
Lots of modules install data types. From con
Tom Lane wrote:
> Bruce Momjian writes:
> > Are there any pg_migrator affects in this patch? We had discussed this
> > issue in the past with this patch.
>
> The code is upward compatible with the old on-disk format, so that
> end of things is fine.
>
> There's still the issue of how to get the
Bruce Momjian writes:
> Are there any pg_migrator affects in this patch? We had discussed this
> issue in the past with this patch.
The code is upward compatible with the old on-disk format, so that
end of things is fine.
There's still the issue of how to get the improved module definition
(new
Tom Lane wrote:
> Andrew Gierth writes:
> > Hstore patch incorporating changes as previously discussed.
> > In addition the requested new features of conversions to and from
> > array formats have been added (with docs).
>
> Applied with some mostly-cosmetic editorialization.
Are there any pg_mi
Tom Lane wrote:
> > I intentionally avoided hstore_to_array because it would be unclear
> > which one it meant (the 1-d or 2-d result).
>
> hstore_to_list seems like a pretty horrible name though for something
> that produces an array. I also note that "array" means "1-D array"
> according to no
> "Tom" == Tom Lane writes:
>> And there was much rejoicing
Tom> ... except in the buildfarm. Must be some platform dependency
Tom> we both missed ...
"oops"
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
"David E. Wheeler" writes:
> On Sep 30, 2009, at 12:52 PM, Tom Lane wrote:
>> Applied with some mostly-cosmetic editorialization.
> And there was much rejoicingÂ…
... except in the buildfarm. Must be some platform dependency we both
missed ...
regards, tom lane
--
Sent
On Sep 30, 2009, at 12:52 PM, Tom Lane wrote:
Applied with some mostly-cosmetic editorialization.
And there was much rejoicing…
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Gierth writes:
> Hstore patch incorporating changes as previously discussed.
> In addition the requested new features of conversions to and from
> array formats have been added (with docs).
Applied with some mostly-cosmetic editorialization.
regards, tom lane
--
On Sep 29, 2009, at 5:00 PM, Andrew Gierth wrote:
David> Sure. But I realized that I forgot to ask for
David> array_to_hstore() and matrix_to_hstore(). :-) Would love to
David> have those, too. Not sure about the operators…
hstore(text[]) (which is also present as an explicit cast) covers both
> "David" == "David E Wheeler" writes:
>> I don't feel particularly strongly about the name (I've also
>> intentionally held off on updating the pgfoundry version of the
>> code until this is settled so no-one else should care either).
David> I'm down with hstore_to_array() and hstore_to
On Sep 29, 2009, at 4:11 PM, Andrew Gierth wrote:
I don't feel particularly strongly about the name (I've also
intentionally held off on updating the pgfoundry version of the code
until this is settled so no-one else should care either).
I'm down with hstore_to_array() and hstore_to_matrix().
> I don't feel particularly strongly about the name (I've also
> intentionally held off on updating the pgfoundry version of the code
> until this is settled so no-one else should care either).
Well, since we already have string_to_array, hstore_to_array would be
consistent.
--
Josh Berkus
Post
> "Tom" == Tom Lane writes:
David> * More name stuff: Why `hstore_to_list` rather than
David> `hstore_to_array`? And I'm not sure about `hstore_to_matrix`
David> for the 2-dimensional array. I guess that's better than
David> `hstore_to_multidimensional_array` would be. ;-)
>> I intent
[ starting to look at this now... ]
Andrew Gierth writes:
> "David" == "David E Wheeler" writes:
> David> * More name stuff: Why `hstore_to_list` rather than
> David> `hstore_to_array`? And I'm not sure about `hstore_to_matrix`
> David> for the 2-dimensional array. I guess that's better tha
On Sep 23, 2009, at 5:27 PM, Andrew Gierth wrote:
I intentionally avoided hstore_to_array because it would be unclear
which one it meant (the 1-d or 2-d result).
Thanks Andrew.
Given these replies, unless anyone else wants to weigh in on the array
conversion operator and function names, thi
> "David" == "David E Wheeler" writes:
David> Just a few thoughts for discussion:
David> * From my previous posts: Is it time to kill off `...@` and `~`,?
David> Not necessarily for your patch to handle, just wondering what
David> others think.
I'll take them out if people think that is
On Sep 22, 2009, at 7:18 PM, Andrew Gierth wrote:
Hstore patch incorporating changes as previously discussed.
In addition the requested new features of conversions to and from
array formats have been added (with docs).
Thanks Andrew.
Just a few thoughts for discussion:
* From my previous po
28 matches
Mail list logo
