Re: Fix missing space before WHERE in `GRAPH_TABLE` deparse

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Chauhan Dhruv <chauhandhruv351(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, peter(at)eisentraut(dot)org
Subject: Re: Fix missing space before WHERE in `GRAPH_TABLE` deparse
Date: 2026-07-30 03:01:58
Message-ID: CAExHW5vtWEeH+-GuMj--ZQyRZ_h16rEFLrXizH8Mrk8eaWTs-A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 25, 2026 at 2:57 PM Chauhan Dhruv <chauhandhruv351(at)gmail(dot)com>
wrote:

> Hi,
>
> *Issue:*
> The `get_graph_pattern_def()` function omits a leading space before the
> WHERE keyword when a GRAPH_TABLE graph pattern includes a WHERE clause.
> This produces incorrectly formatted SQL during reverse-parsing. e.g.
>
> ... (o IS orders)WHERE (c.address = 'US'::text) COLUMNS ...
>
> Notice the missing space between ) and WHERE.
>
> *Root Cause:*
> The pattern-level WHERE deparse doesn't add a leading space, while the
> element-level WHERE deparse already does. This inconsistency creates
> malformed output.
>
> *Solution:*
> The patch changes the pattern-level branch to emit " WHERE " (with leading
> space) instead of "WHERE ", matching the element-level behavior. Although
> the SQL still re-parses correctly (making this cosmetic), the formatted
> output is now correct.
>
>
I wouldn't call it "incorrectly formatted SQL" since it gets parsed without
any error and has the same semantics as with space. I agree that the
deparsed string is not readable. The fix looks good to me.

> Also adds a regression test for whole-pattern WHERE clauses. make check is
> green. Patch is against master.
>
>
Instead of creating another view, I would try to add the WHERE clause in
customer_us definition itself. I don't think we can add a WHERE clause
which has any meaningful effect on the contents on the view. It will still
show the effect of deparsing and since the view is not used in any query,
its actual contents can be ignored.

Further, we usually don't drop any objects created by this test so that
they can be tested in the 002_pg_upgrade test. Please observe that
customer_us view is not dropped.

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2026-07-30 03:12:25 Re: pg19b1: stuck in LockBuffer
Previous Message Peter Geoghegan 2026-07-30 02:59:13 Re: pg19b1: stuck in LockBuffer