Re: jsonb and nested hstore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Thom Brown <thom(at)linux(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb and nested hstore
Date: 2014-02-28 19:00:32
Message-ID: 15614.1393614032@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> But anyway, I think we've seen enough of these to conclude that the casts
>> from hstore to jsonb and back should not be implicit. I am fairly confident
>> that changing that would fix your complaint and the similar one that Peter
>> Geoghegan had.

> Yes, it will, but I think that that will create more problems than it
> will solve (which is not to suggest that an implicit cast is the right
> thing). That will require that any non-trivial usage of jsonb requires
> copious casting, where nested hstore does not. The hstore module
> hardly contains some nice extras that a minority of jsonb users will
> be interested in. It contains among other basic things, operator
> classes required to index jsonb. All of my examples will still not
> work, plus a bunch of cases that currently do work reasonably well.
> There'll just be a different error message.

We should have learned by now that implicit casts are generally pretty
dangerous things. I think putting in implicit casts as a band-aid for
missing functionality is a horrid idea that we'll regret for a long
time to come. I gather from upthread comments that the patch currently
actually creates implicit casts in *both* directions? That's doubly
horrid/dangerous.

The more I read in this thread, the more I think that jsonb simply
isn't ready. We should put it off to 9.5 so that we can have a
complete implementation without so many rough edges. I'm afraid that
if we ship it as-is, backwards compatibility considerations are going
to prevent us from filing down the rough edges in future.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-02-28 19:02:37 Re: patch: option --if-exists for pg_dump
Previous Message Fabrízio de Royes Mello 2014-02-28 18:55:02 Re: proposal: new long psql parameter --on-error-stop