On 3/18/14, 12:13 PM, Greg Stark wrote:
> Fwiw I'm finding myself repeatedly caught up by the operator
> precedence rules when experimenting with jsonb:
>
> stark=***# select segment->'id' as id from flight_segments where
> segment->>'marketing_airline_code' <>
> segment->>'operating_airline_code' ;
> ERROR: 42883: operator does not exist: text <> jsonb
> LINE 2: ...segments where segment->>'marketing_airline_code' <> segment...
> ^
> HINT: No operator matches the given name and argument type(s). You
> might need to add explicit type casts.
> LOCATION: op_error, parse_oper.c:722
> Time: 0.407 ms
> stark=***# select segment->'id' as id from flight_segments where
> (segment->>'marketing_airline_code') <>
> (segment->>'operating_airline_code') ;
> id
> -------------
> "45866185"
> "95575359"
> ....
>
> I don't think this is related to the jsonb patch -- json and hstore
> have the same behaviour so jsonb is obviously going to follow suit.
> The only option right now would be to use a higher precedence operator
> like % or ^ for all of these data types which I'm not for. I suspect
> it's a pipe dream to think we might be able to override the '.' and
> changing the precedence of -> and ->> would be fraught...
>
> I think the best we can do is to highlight it in the docs.
>
> Incidentally it's a good thing there wasn't an implicit cast
> text->jsonb. In this case it would have resulted in just a confusing
> error of jsonb->>boolean not existing.
Wow, that really sucks. :(
What are cases where things would break if we changed the precedence of -> and ->>? ISTM that's what we really should
doif there's some way to manage the backwards compatibility...
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
