On Mon, Mar 3, 2014 at 5:09 PM, Josh Berkus <josh@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