On Thu, 9 Jul 2026 at 20:52, Alexander Korotkov <[email protected]> wrote:
>
> Hi, Thom!
>
> On Thu, Jul 9, 2026 at 7:12 PM Thom Brown <[email protected]> wrote:
> > On Wed, 8 Jul 2026 at 18:04, Alexander Korotkov <[email protected]>
> > wrote:
> > >
> > > On Wed, Jul 8, 2026 at 6:35 PM Nikita Malakhov <[email protected]> wrote:
> > > > Alexander, thank you for your participation. I am very sorry, I've seen
> > > > your previous
> > > > email but was busy with other tasks and didn't have time to work on
> > > > your notes.
> > > > Thank you very much!
> > >
> > > OK, no problem. Are you good with the current shape of the patch?
> >
> > I've been giving this a test drive. I saw that this has been
> > committed, and re-tested against that, and the issues I identified
> > (unless I've misunderstood some functionality) seem to have survived.
>
> I tried my best to check if all the critics is addressed. SQL/JSON patches
> go through so many threads. Sorry that I missed your valuable insights.
You didn't miss anything from me, so nothing to be sorry about. I just
meant I retested the issues I had found against the commit to see if
they had been fixed prior to submitting them. I hadn't raised them
prior to today.
> > First, doesn't this need a catversion bump? This adds fields to
> > existing node types.
>
> Thank you for noticing, catversion is bumped.
>
> > I only get the first column from the following. The second one
> > disappears without error:
> >
> > SELECT * FROM JSON_TABLE(
> > jsonb '[{"x":[1],"y":[2]}]', '$[*]' AS p0
> > COLUMNS (
> > NESTED PATH '$.x[*]' AS json_table_path_0 COLUMNS (x int PATH '$'),
> > NESTED PATH '$.y[*]' COLUMNS (y int PATH '$')
> > )
> > PLAN (p0 OUTER json_table_path_0)
> > ) jt;
> > x
> > ---
> > 1
> > (1 row)
>
> Yes, there is a bug in assignment of generated names. Fixed in 0003.
>
> > I have the following view:
> > CREATE VIEW v_chain AS
> > SELECT * FROM JSON_TABLE(
> > jsonb '[{"x": [{"y": [1,2]}]}]', '$[*]' AS p0
> > COLUMNS ( NESTED PATH '$.x[*]' AS p1 COLUMNS (
> > NESTED PATH '$.y[*]' AS p11 COLUMNS ( y int PATH '$' ) ) )
> > PLAN (p0 OUTER (p1 INNER p11))
> > ) jt;
> >
> > When I dump it, I get:
> >
> > CREATE VIEW public.v_chain AS
> > SELECT y
> > FROM JSON_TABLE(
> > '[{"x": [{"y": [1, 2]}]}]'::jsonb, '$[*]' AS p0
> > COLUMNS (
> > NESTED PATH '$."x"[*]' AS p1
> > COLUMNS (
> > NESTED PATH '$."y"[*]' AS p11
> > COLUMNS (
> > y integer PATH '$'
> > )
> > )
> > )
> > PLAN (p0 OUTER p1 INNER p11)
> > ) jt;
> >
> > The parentheses around "p1 INNER p11" aren't preserved.
>
> Yes, there is a bug in the deparsing. 0002 fixes that.
>
> > Another dump issue with the following:
> >
> > CREATE VIEW v_onempty AS SELECT * FROM JSON_TABLE(
> > jsonb '{}', '$' AS p0
> > COLUMNS ( a int PATH '$.nosuch' ERROR ON EMPTY )
> > ERROR ON ERROR
> > ) jt;
> >
> > This dumps as:
> >
> > CREATE VIEW public.v_onempty AS
> > SELECT a
> > FROM JSON_TABLE(
> > '{}'::jsonb, '$' AS p0
> > COLUMNS (
> > a integer PATH '$."nosuch"'
> > ) ERROR ON ERROR
> > ) jt;
> >
> > It's lost "ERROR ON EMPTY".
> >
> >
> > Another example:
> >
> > SELECT * FROM JSON_TABLE(jsonb '"mystring"', '$'
> > COLUMNS (a int PATH '$')
> > ERROR ON ERROR
> > ) jt;
> >
> > This gives me:
> >
> > ERROR: invalid input syntax for type integer: "mystring"
> >
> > But the documentation says that the table-level clause "does not
> > affect the errors that occur when evaluating columns". Am I missing
> > something here?
>
> I've rechecked with SQL 2023 standard. AFAICS, ON ERROR clause should
> be propagated from table to column. We don't propagate it, so that must be
> a bug since PG 17. But this patch shouldn't try to change it, it's out of
> scope.
> 0001 reverts attempt to change ON ERROR handling (this also fixes the case
> about of invalid dumpinged). I think we need to consider this subject
> separately.
Yeah, I haven't exercised JSON_TABLE enough since release, so I'm
clearly late in hitting this.
Thanks for the fixes. I'll try to get round to testing them tomorrow
unless someone beats me to it.
Thom
