Re: jsonb and nested hstore

On Mon, Mar 3, 2014 at 8:59 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Okay, that's fine. I'm sure that jsonb has some value without
>> hstore-style indexing. That isn't really in question. What is in
>> question is why you would choose to give up on those capabilities.
>
>
>
> Who has given up?
>
> I did as much as I could given the time constraints I mentioned. That's the
> way Postgres works. People do what they can.

It would be such a small amount of additional effort to add those
operators sufficient to make those operator classes work, relative to
the huge benefits. The code already exists, there isn't terribly much
of it, and is isn't scarier than what you already have. I cannot
fathom how you could choose to not do so, as long as you wanted a
jsonb type in core. It is just not sensible.

>> But the equivalent code to the proposed hstore operator classes is
>> *exactly the same* C code. The two types are fully binary coercible in
>> the patch, so why delay? Why is that additional step appreciably
>> riskier than adopting jsonb? I don't see why the functions associated
>> with the operators that comprise, say, the gin_hstore_ops operator
>> class represent much additional risk, assuming that jsonb is itself in
>> good shape. For example, the new hstore_contains() looks fairly
>> innocuous compared to much of the code you are apparently intent on
>> including in the first cut at jsonb. Have I missed something? Why are
>> those operators riskier than the operators you are intent on
>> including?
>
>
>
> You are really jumping at conclusions as to what's in my head, conclusions
> that are not justified by anything I have said.

Right - they are conclusions justified by what you have not said, and
my attempt to fill in the gaps.

> Who said they were riskier? I certainly didn't.
>
> Of course the operators would be the same. We could have them today, by
> migrating the exisiting code into core and making the hstore operators use
> that code instead. I could probably do it in about a day (if I had a day to
> spare). I was actually rather expecting that they would have been put there
> for the jsonb type when Teodor moved some code so we could have a jsonb
> type. But since he didn't we find ourselves where we are today.
>
> If that's what it will take to get agreement I will try to make it happen.

I'll do it if you really are that strapped for time.

> Well, the trouble is that the only one that would make sense is one that did
> in effect "order by i::json", since it would be weird to have these
> different. That might make the ordering slow, but would be easy enough to
> add.

No, it would not be weird to have those be different. In some cases it
would be totally mandatory, as for example when there is a variable
lc_numeric setting that affects the format of numeric. Only text
equality is equivalent to a binary string comparison.

> I think you need to be more accepting of the fact that Postgres development
> is frequently incremental. Nothing that's been proposed would prevent future
> development of the type AFAICT. Enums took us two or three releases to get
> to where we are. Arrays took longer. Even a smallish feature like CSV import
> is still being tweaked about seven releases after it was introduced.

My objection is that the cost/benefit analysis behind the idea of
excluding the hstore operator classes seem to make no sense.

-- 
Peter Geoghegan