On 02/28/2014 03:19 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> That hasn't been the way we've done things in the past. We're frequently
>> incremental. New features sometimes take several releases to mature.
> That's perfectly fair. What I don't want to see is a user-visible
> dependency from jsonb to hstore. I think that'll be a mess that will
> take years to undo. I'd rather say "sorry, that functionality isn't
> there yet for jsonb" than have such a dependency.
>
> Maybe we're in violent agreement.
>
>
Maybe we are.
There's actually no real dependency. In fact, the dependency is the
other way. The jsonb patches I have been posting could be committed and
pass every regression test and we'd have useful better performance for
some operations. Every json function has an analog in jsonb except the
generator functions (to_json and friends), and they use the same parser
so they accept exactly the same input. The only "dependency" is if you
want to be able to use some advanced indexing and other functionality,
for which we don't currently have jsonb equivalents of the new hstore
operators, because we ran out of time. Then you can get this
functionality by casting the data to hstore (assuming we also have
nested-hstore committed) and using its operators. But that's no more a
dependency than it is for any other type for which you can leverage this
functionality (e.g. any record type).
cheers
andrew
