From: | Peter Krauss <ppkrauss(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | problem with precendence order in JSONB merge operator |
Date: | 2016-03-22 20:52:22 |
Message-ID: | CAHEREtuOz=_R+aoF+21T0NSmRrbrur7ZGo512jChXA_Ahg7ekw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Seems that parser not using precedence ideal order, and that casting
obligation losts performance.
The first problem is self-evident in this example:
SELECT '{"x":1}'::jsonb || (('{"A":{"y":2}}'::jsonb)->'A')
-- it is ok, expected result with (x,y)
SELECT '{"x":1}'::jsonb || '{"A":{"y":2}}'::jsonb)->'A'
-- non-expected result (y).
Higher precedence <https://en.wikipedia.org/wiki/Order_of_operations> most
be for -> operator, that is like an object-oriented *path* operator, always
higher than algebric ones.
Other problem is using this operation as SQL function,
CREATE FUNCTION term_lib.junpack(jsonb,text) RETURNS JSONB AS $f$
SELECT ($1-$2)::JSONB || ($1->>$2)::JSONB;
$f$ LANGUAGE SQL IMMUTABLE;
without casting produce error. Perhaps will be "more friendly" without cast
obligation,
and it is a performance problem, the abusive use of castings losts
performance.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-03-22 20:53:28 | Re: WIP: Access method extendability |
Previous Message | Grzegorz Sampolski | 2016-03-22 20:29:59 | Re: pam auth - add rhost item |