Re: [HACKERS] updated hstore patch

2010-02-22 Thread Bruce Momjian
Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: On Sep 20, 2009, at 8:43 AM, Tom Lane wrote: Yeah, this is a long-standing generic issue, and not really hstore's problem to fix. So then does there need to be some documentation for how to deal with this, for those doing

Re: [HACKERS] updated hstore patch

2009-09-21 Thread David E. Wheeler
On Sep 20, 2009, at 3:14 PM, Andrew Gierth wrote: I think you're missing the point here; I can't control what it resolves to, since that's the job of the function overload resolution code. Yeah, but I think that the existing behavior is probably the best. But I checked, and

Re: [HACKERS] updated hstore patch

2009-09-21 Thread David E. Wheeler
On Sep 20, 2009, at 12:15 PM, Tom Lane wrote: That recipe doesn't actually work for cases like this. What *would* work is loading the module *before* restoring from your old dump, then relying on the CREATEs from the incoming dump to fail. Jesus this is hacky, either way. :-( I believe we

Re: [HACKERS] updated hstore patch

2009-09-21 Thread Andrew Gierth
David == David E Wheeler da...@kineticode.com writes: But I checked, and delete(hstore,$1) still resolves to delete(hstore,text) when the type of $1 is not specified, so there's no compatibility issue there that I can see. (I'm not sure I understand _why_ it resolves to that rather than

Re: [HACKERS] updated hstore patch

2009-09-21 Thread David E. Wheeler
On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote: I don't think there's any way to do that from the regression tests. The output that you demonstrated a few messages back should do nicely for delete(), at least: contrib_regression=# explain verbose select delete(('a' =

Re: [HACKERS] updated hstore patch

2009-09-21 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote: I don't think there's any way to do that from the regression tests. The output that you demonstrated a few messages back should do nicely for delete(), at least: Anything involving 'explain

Re: [HACKERS] updated hstore patch

2009-09-21 Thread Andrew Gierth
Tom == Tom Lane t...@sss.pgh.pa.us writes: On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote: I don't think there's any way to do that from the regression tests. The output that you demonstrated a few messages back should do nicely for delete(), at least: Tom Anything involving

Re: [HACKERS] updated hstore patch

2009-09-21 Thread Tom Lane
Andrew Gierth and...@tao11.riddles.org.uk writes: Is delete('...'::hstore,'foo') guaranteed to resolve to the same function as delete('...'::hstore,$1) where $1 has no type specified? Yup. They're both UNKNOWN. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] updated hstore patch

2009-09-20 Thread Andrew Gierth
Tom == Tom Lane t...@sss.pgh.pa.us writes: David E. Wheeler da...@kineticode.com writes: ... I think that this patch is ready for committer review and, perhaps, committing. The code looks clean (though mainly over my head) and the functionality is top-notch. Tom Given the number of

Re: [HACKERS] updated hstore patch

2009-09-20 Thread Ron Mayer
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

Re: [HACKERS] updated hstore patch

2009-09-20 Thread Tom Lane
Ron Mayer rm...@cheapcomplexdevices.com writes: Andrew Gierth wrote: - 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

Re: [HACKERS] updated hstore patch

2009-09-20 Thread David E. Wheeler
On Sep 18, 2009, at 6:27 PM, Andrew Gierth wrote: However, I would prefer to keep the ability to do this: psql --set hstore_schema='myschema' -f hstore.sql dbname The logic to do it is a bit ugly, but editing the file to set what schema to use is even uglier... Yes, this should perhaps

Re: [HACKERS] updated hstore patch

2009-09-20 Thread David E. Wheeler
On Sep 20, 2009, at 8:43 AM, Tom Lane wrote: 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. Yeah, this is a long-standing generic issue, and not really hstore's problem to fix. So

Re: [HACKERS] updated hstore patch

2009-09-20 Thread David E. Wheeler
On Sep 20, 2009, at 1:03 AM, Andrew Gierth wrote: I will resubmit (hopefully in a day or two) with the following changes: - removal of the \set schema variable stuff from the .sql script - documentation fixes as mentioned in my previous email - additional documentation for some of the newer

Re: [HACKERS] updated hstore patch

2009-09-20 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: On Sep 20, 2009, at 8:43 AM, Tom Lane wrote: Yeah, this is a long-standing generic issue, and not really hstore's problem to fix. So then does there need to be some documentation for how to deal with this, for those doing an in-place upgrade

Upgrading towards managed extensions (was Re: [HACKERS] updated hstore patch)

2009-09-20 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: I believe we have already discussed the necessity for pg_upgrade to support this type of subterfuge. A module facility would be a lot better of course, but we still need something for upgrading existing databases that don't contain the module structure. An

Re: [HACKERS] updated hstore patch

2009-09-20 Thread Andrew Gierth
David == David E Wheeler da...@kineticode.com writes: The only open question I can see is what delete(hs,$1) resolves to when $1 is an unknown-type placeholder; this is probably an incompatibility with the old version if anyone is relying on that (but I don't see why they would be).

Re: [HACKERS] updated hstore patch

2009-09-19 Thread Magnus Hagander
On Sat, Sep 19, 2009 at 03:27, Andrew Gierth and...@tao11.riddles.org.uk wrote: However, I would prefer to keep the ability to do this: psql --set hstore_schema='myschema' -f hstore.sql dbname The logic to do it is a bit ugly, but editing the file to set what schema to use is even uglier...

Re: [HACKERS] updated hstore patch

2009-09-19 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: ... I think that this patch is ready for committer review and, perhaps, committing. The code looks clean (though mainly over my head) and the functionality is top-notch. Given the number of questions in your review, I don't think this is

Re: [HACKERS] updated hstore patch

2009-09-19 Thread David E. Wheeler
On Sep 19, 2009, at 7:03 PM, Tom Lane wrote: Given the number of questions in your review, I don't think this is actually ready to commit. I'm marking it waiting on author instead. Yes, actually, I had second thoughts about that and meant to change it myself. Thanks Tom. David -- Sent

Re: [HACKERS] updated hstore patch

2009-09-18 Thread David E. Wheeler
On Sep 15, 2009, at 8:31 PM, Andrew Gierth wrote: Gah. rerolled to fix a missing file. includes the docs too this time. Yay, thank you Andrew! Here are my review notes. Testing === Here's what I did to try out the patch, paying special attention to in- place upgrading: * I built a

Re: [HACKERS] updated hstore patch

2009-09-18 Thread Andrew Gierth
David == David E Wheeler da...@kineticode.com writes: David * I ran the following to update the SQL functions in my simple database: Davidpsql -d try --set hstore_xact='--' -f hstore.sql DavidThe use of `--set hstore_xact='--' was on Andrew's advice Davidvia IRC, because

Re: [HACKERS] updated hstore patch

2009-09-15 Thread Andrew Gierth
Gah. rerolled to fix a missing file. includes the docs too this time. -- Andrew (irc:RhodiumToad) hstore-20090915.patch.gz Description: hstore patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: