On Mon, Mar 3, 2014 at 5:09 PM, Josh Berkus <j...@agliodbs.com> wrote: > On 03/03/2014 05:07 PM, Peter Geoghegan wrote: >>> Primary value is that in theory the hstore2 opclasses are available >>> *now*, as opposed to a year from now. >> >> Well, yes, that's right. Although we cannot assume that VODKA will get >> into 9.5 - it's a big project. Nor is it obvious to me that a >> VODKA-ized set of operator classes would not bring with them exactly >> the same dilemma as we now face vis-a-vis hstore code reuse and GIN >> operator classes. So it seems reasonable to me to suppose that VODKA >> should not influence our decision here. Please correct me if I'm >> mistaken. > > I would agree with you.
Good. Hopefully you also mean that you recognize the dilemma referred to above - that the hstore code reuse made a certain amount of sense, and that more than likely the best way forward is to work out a way to make it work. I'm not immediately all that concerned about what the least worst way of doing that is (I just favor putting everything in hstore on practical grounds). Another way to solve this problem might be to simply live with the code duplication between core and hstore on the grounds that hstore will eventually be deprecated as people switch to jsonb over time (so under that regime nothing new would ever be added to hstore, which we'd eventually remove from contrib entirely, while putting everything new here in core). I don't favor that approach, but it wouldn't be totally unreasonable, based on the importance that is attached to jsonb, and based on what I'd estimate to be the actual amount of code redundancy that that would create (assuming that hstore gets no new functions and operators, since an awful lot of the hstore-local code after this patch is applied is new to hstore). I wouldn't stand in the way of this approach. In my view the most important thing right now is that before anything is committed, at the very least there needs to be a strategy around getting hstore-style GIN indexing in jsonb. I cannot understand how you can have an operator class today that works fine for hstore-style indexing of jsonb (as far as that goes), but that that code is out of bounds just because it's nominally (mostly new) hstore code, and you cannot figure out a way of making that work that is acceptable from a code maintenance perspective. If you cannot figure that out in a few days, why should you ever be able to figure it out? We need to bite the bullet here, whatever that might actually entail. Can we agree on that much? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers