On Fri, Dec 8, 2023 at 3:42 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> I noticed that JSON_TABLE uses an explicit FORMAT JSON in one of the
> rules, instead of using json_format_clause_opt like everywhere else. I
> wondered why, and noticed that it's because it wants to set coltype
> JTC_FORMATTED when the clause is present but JTC_REGULAR otherwise.
> This seemed a little odd, but I thought to split json_format_clause_opt
> in two productions, one without the empty rule (json_format_clause) and
> another with it. This is not a groundbreaking improvement, but it seems
> more natural, and it helps contain the FORMAT stuff a little better.
>
> I also noticed while at it that we can do away not only with the
> json_encoding_clause_opt clause, but also with makeJsonEncoding().
>
> The attach patch does it. This is not derived from the patches you're
> currently working on; it's more of a revise of the previous SQL/JSON
> code I committed in 7081ac46ace8.
>
> It goes before your 0003 and has a couple of easily resolved conflicts
> with both 0003 and 0004; then in 0004 you have to edit the JSON_TABLE
> rule that has FORMAT_LA and replace that with json_format_clause.
Thanks. I've adapted that as the attached 0004.
I started thinking that some changes to
src/backend/utils/adt/jsonpath_exec.c made by SQL/JSON query functions
patch belong in a separate refactoring patch, which I've attached as
patch 0003. They are the changes related to how jsonpath executor
takes and extracts "variables".
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com