From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Further issues with jsonb semantics, documentation |
Date: | 2015-06-05 19:51:29 |
Message-ID: | 20150605195129.GY133018@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby wrote:
> On 6/5/15 2:08 PM, Petr Jelinek wrote:
> >That's a good point, and it won't get any better if/when we add the json
> >point support in 9.6 since the syntax would be something like select
> >jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' - '/c/a'; and we will again
> >silently do nothing. That's going to cause bugs in applications using this.
>
> Yeah, this is a miniature version of the pain I've felt with variant: trying
> to get sane casting for a data type that encompasses other types in current
> Postgres is essentially impossible.
I'm not sure this is the same problem. But anyway I think requiring
explicit casts in this stuff is a good thing -- relying on implicit
cast to text, when most useful behavior uses other types, seems bad.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-06-05 20:02:37 | Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
Previous Message | Jeff Janes | 2015-06-05 19:27:01 | Re: RFC: Remove contrib entirely |