On 02/28/2014 03:19 PM, Tom Lane wrote:
Andrew Dunstan <and...@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).



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to