Hi, hackers! I have a question about transformation of JSON constructors into executor nodes.
In first letter in this thread we wrote: JSON_OBJECT(), JSON_ARRAY() constructors and IS JSON predicate are transformed into raw function calls. Here is an example explaining what it means: =# CREATE VIEW json_object_view AS SELECT JSON_OBJECT('foo': 1, 'bar': '[1,2]' FORMAT JSON RETURNING text); CREATE VIEW =# \sv json_object_view CREATE OR REPLACE VIEW public.json_object_view AS SELECT json_build_object_ext(false, false, 'foo', 1, 'bar', '[1,2]'::text::json)::text As you can see JSON_OBJECT() was transformed into a call on new function json_build_object_ext(), which shares a code with existing json_build_object() but differs from it only by two additional boolean parameters for representation of {WITH|WITHOUT} UNIQUE [KEYS] and {NULL|ABSENT} ON NULL clauses. Information about FORMAT, RETURNING clauses was lost, since they were transformed into casts. Other constructors are transformed similary: JSON_ARRAY() => json[b]_build_array_ext(boolean, VARIADIC any) JSON_OBJECTAGG() => json[b]_objectagg(any, any, boolean, boolean) JSON_ARRAYAGG() => json[b]_agg[_strict](any) Also there is a variant of JSON_ARRAY() with subquery which transformed into a subselect with json[b]_agg(): =# CREATE VIEW json_array_view AS SELECT JSON_ARRAY(SELECT generate_series(1,3)); CREATE VIEW =# \sv json_array_view CREATE OR REPLACE VIEW public.json_array_view AS SELECT ( SELECT json_agg_strict(q.a) FROM ( SELECT generate_series(1, 3) AS generate_series) q(a)) And here is my question: is it acceptable to do such transformations? And if is not acceptable (it seemed unacceptable to us from the beginning, but we did not have time for correct implementation), how should JSON constructor nodes look like? The simplest solution that I can propose is to save both transformed expressions in existing JsonObjectCtor/JsonArrayCtor nodes which exist now only in untransformed trees. Whole untransformed JsonXxxCtor node will be used for displaying, transformed expression -- for execution only. But it will not work for aggregates, because they are transformed into a Aggref/WindowFunc node. Information needed for correct displaying should be saved somewhere in these standard nodes. And for subquery variant of JSON_ARRAY I can only offer to leave transformation into a subselect with JSON_ARRAYAGG(): JSON_ARRAY(query) => (SELECT JSON_ARRAYAGG(bar) FROM (query) foo(bar)) -- Nikita Glukhov Postgres Professional:http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers