Tom Lane wrote:
> "David E. Wheeler" 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 i
Andrew Gierth 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 (pgsql-hackers@postgresql
> "Tom" == Tom Lane 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 'explai
"David E. Wheeler" 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 verbose' output is
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' =>
now()::text),'a')
> "David" == "David E Wheeler" 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 bein
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 h
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 delete(hstore,$
> "David" == David E Wheeler 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).
David> G
Tom Lane 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 idea would be
"David E. Wheeler" 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 from an existi
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 then
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 f
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 be
Ron Mayer 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 a dump/restore from
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 indepen
> "Tom" == Tom Lane writes:
> "David E. Wheeler" 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 questions in your rev
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
"David E. Wheeler" 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
actually ready to comm
On Sat, Sep 19, 2009 at 03:27, 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...
That seems like a pre
> "David" == "David E Wheeler" writes:
David> * I ran the following to update the SQL functions in my simple database:
David>psql -d try --set hstore_xact='--' -f hstore.sql
David>The use of `--set hstore_xact='--' was on Andrew's advice
David>via IRC, because otherwise
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 sim
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:
http://www.postgresql.org/mailpref/
23 matches
Mail list logo
