From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: updated hstore patch |
Date: | 2009-09-20 22:14:22 |
Message-ID: | 87k4ztgt6p.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "David" == David E Wheeler <david(at)kineticode(dot)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).
David> Given your examples, I think it probably should resolve to
David> text as it does, as deleting a single key is likely to be a
David> common case. It should otherwise be cast.
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.
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 being ambiguous...)
>> The overhead is possibly non-negligible for reading old values,
>> but old values can be promoted to new ones fairly simply
>> (e.g. using ALTER TABLE).
David> So then it's negligible for new values?
Yes. (One bit test, done inline)
--
Andrew.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2009-09-20 23:09:43 | Re: operator exclusion constraints [was: generalized index constraints] |
Previous Message | Robert Haas | 2009-09-20 21:58:03 | Re: generic copy options |