Re: SQL/JSON: JSON_TABLE

From: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
To: Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Subject: Re: SQL/JSON: JSON_TABLE
Date: 2021-01-21 01:42:39
Message-ID: cf448269-f62f-b0ac-14d0-1972ac3a8c3a@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you for review.

Attached 45th version of the patches. "SQL/JSON functions" patch corresponds to
v52 patch set posted in the separate thread.

On 27.12.2020 01:16, Zhihong Yu wrote:
> For new files introduced in the patches:
>
> + * Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
>
> 2021 is a few days ahead. It would be good to update the year range.

Fixed.

> For transformJsonTableColumn:
>
> +   jfexpr->op =
> +       jtc->coltype == JTC_REGULAR ? IS_JSON_VALUE :
> +       jtc->coltype == JTC_EXISTS ? IS_JSON_EXISTS : IS_JSON_QUERY;
>
> Should IS_JSON_EXISTS be mentioned in the comment preceding the method ?

Added mention of EXISTS PATH column to the comment.

> For JsonTableDestroyOpaque():
>
> +   state->opaque = NULL;
>
> Should the memory pointed to by opaque be freed ?

I think it's not necessary, because FunctionScan, caller of
JsonTableDestroyOpaque(), will free it and also all opaque's fields using
MemoryContextReset().

>
> +   l2 = list_head(tf->coltypes);
> +   l3 = list_head(tf->coltypmods);
> +   l4 = list_head(tf->colvalexprs);
>
> Maybe the ListCell pointer variables can be named corresponding to the
> lists they iterate so that the code is easier to understand.

Variable were renamed, also foreach() loop was refactored using forfour() macro.

>
> +typedef enum JsonTablePlanJoinType
> +{
> +   JSTP_INNER = 0x01,
> +   JSTP_OUTER = 0x02,
> +   JSTP_CROSS = 0x04,
>
> Since plan type enum starts with JSTP_, I think the plan join type
> should start with JSTPJ_ or JSTJ_. Otherwise the following would be a
> bit hard to read:
>
> +   else if (plan->plan_type == JSTP_JOINED)
> +   {
> +       if (plan->join_type == JSTP_INNER ||
> +           plan->join_type == JSTP_OUTER)
>
> since different fields are checked in the two if statements but the
> prefixes don't convey that.

Enumeration members were renames using prefix JSTPJ_.

> +      Even though the path names are not incuded into the
> <literal>PLAN DEFAULT</literal>
>
> Typo: incuded -> included

Fixed.

> +   int         nchilds = 0;
>
> nchilds -> nchildren

Fixed.

>
> +#if 0 /* XXX it' unclear from the standard whether root path name is
> mandatory or not */
> +   if (plan && plan->plan_type != JSTP_DEFAULT && !rootPathName)
>
> Do you plan to drop the if block ?

If it becomes clear, I will drop it.

--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
0001-SQL-JSON-functions-v45.patch.gz application/gzip 86.5 KB
0002-JSON_TABLE-v45.patch.gz application/gzip 26.6 KB
0003-JSON_TABLE-PLAN-DEFAULT-clause-v45.patch.gz application/gzip 6.9 KB
0004-JSON_TABLE-PLAN-clause-v45.patch.gz application/gzip 12.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-01-21 01:45:12 Re: POC: postgres_fdw insert batching
Previous Message Craig Ringer 2021-01-21 01:42:35 Re: Printing backtrace of postgres processes