> Thanks for looking into this, currently for this patch set, i am following
> SQL
> standard but I'd really like the community's view on the overall direction
> for JSON_TRANSFORM: should we follow the SQL standard strictly, aim for
> Oracle compatibility, or take a Postgres-native approach where they
> conflict? I'm happy to go whichever way there's consensus on.
I would prefer the approach of following the standard - it just means
I can't review it with standard compliance in mind, as I only have
access to the publicly available oracle documentation.
+ analyzed_jst_action->pathspec = coerced_path_spec;
+ jsexpr->action = analyzed_jst_action;
Shouldn't jsexpr->patch_spec also be set? This currently crashes:
CREATE TABLE t (id int, j jsonb);
CREATE INDEX ON t ((JSON_TRANSFORM(j, REMOVE '$.a'))); -- crash
Another thing I noticed is that deparse support is missing:
EXPLAIN (VERBOSE) SELECT JSON_TRANSFORM('{"a":1}'::jsonb, REMOVE '$.a');
Shouldn't the following statement work?
SELECT JSON_TRANSFORM('{"arr":[{"a":1}]}', REPLACE 'lax $.arr.a' = '9');
