Re: jsonb and nested hstore
От | Andrew Dunstan |
---|---|
Тема | Re: jsonb and nested hstore |
Дата | |
Msg-id | 5310E759.4060708@dunslane.net обсуждение исходный текст |
Ответ на | Re: jsonb and nested hstore (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: jsonb and nested hstore
Re: jsonb and nested hstore |
Список | pgsql-hackers |
On 02/28/2014 02:00 PM, Tom Lane wrote: > 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. I agree. I have removed them in my current tree. > > 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. > > Well, the jsonb portion of this is arguably the most ready, certainly it's had a lot more on-list review. cheers andrew
В списке pgsql-hackers по дате отправления: