Re: jsonb and nested hstore
От | Tom Lane |
---|---|
Тема | Re: jsonb and nested hstore |
Дата | |
Msg-id | 15614.1393614032@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: jsonb and nested hstore (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: jsonb and nested hstore
|
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes: > On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan <andrew@dunslane.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
В списке pgsql-hackers по дате отправления: