Re: jsonb and nested hstore

On Wed, Mar 5, 2014 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> And despite the assertions from various people here that these
>> decisions were all made a long time ago and it's way too late to
>> question them, I don't buy it.  There's not a single email on this
>> mailing list clearly laying out the design that we've ended up with,
>> and I'm willing to wager any reasonable amount of money that if
>> someone had posted an email saying "hey, we're thinking about setting
>> things up so that jsonb and hstore have the same binary format, but
>> you can't index jsonb directly, you have to cast it to hstore, is
>> everyone OK with that?" someone would have written back and said "no,
>> that sounds nuts".  The reason why input on that particular aspect of
>> the design was not forthcoming isn't because everyone was OK with it;
>> it's because it was never clearly spelled out.
>
> No, that was never the design (I trust).  It's where we are today
> because time ran out to complete jsonb for 9.4, and tossing the index
> opclasses overboard was one of the last-minute compromises in order
> to have something submittable.

Well, what I was told when I started objecting to the current state of
affairs is that it was too late to "change course" now, which seemed
to me to imply that this was the idea all along.  On the other hand,
Josh also said that there was a plan in the works to ship the missing
opclasses on PGXN before 9.4 hits shelves, which is more along the
lines of what you're saying.  So, hey, I don't know.

> I think it would be a completely defensible decision to postpone jsonb
> to 9.5 on the grounds that it's not done enough.  Now, Josh has laid out
> arguments why we want jsonb in 9.4 even if it's incomplete.  But ISTM
> that those are fundamentally marketing arguments; on a purely technical
> basis I think the decision would be to postpone.  So it comes down
> to how you weight marketing vs technical issues, which is something
> that everyone is likely to see a little bit differently :-(

I don't have any problem shipping incremental progress on important
features, but once we ship things that are visible at the SQL level
they get awfully hard to change, and my confidence that we won't want
to change this is not very high right now.  To the extent that we have
a jsonb that is missing some features we will eventually want to have,
I don't care; that's incremental development at its finest.  To the
extent that we have a jsonb that makes choices about what to store on
disk or expose at the SQL level that we may regret later, that's not
incremental development; that's just not being done.  Anyone who
thinks that digging ourselves out of a backward-compatibility hole
will be painless enough to justify the marketing value of the feature
has most probably not had to do it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company