Re: doc: Reformat SELECT queries using GRAPH_TABLE

From: Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: doc: Reformat SELECT queries using GRAPH_TABLE
Date: 2026-08-26 01:25:06
Message-ID: OS9P286MB64867F881B1AA850A8F174F794AE2@OS9P286MB6486.JPNP286.PROD.OUTLOOK.COM
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Splitting the path pattern across three lines is really necessary?
> Even without doing that, the full MATCH line would still be around
> 90–100 characters, which seems readable enough.
>
> There is another nearby GRAPH_TABLE example in queries.sgml that
> uses a different formatting style. If this patch is also intended to
> establish a clearer formatting style for GRAPH_TABLE examples,
> isn't it better to adjust that example as well?

Hi,

I agree that splitting the path pattern into three lines wasn't really necessary;
even without it, the MATCH line stays around 90 to 100 characters, which is readable enough.
I've put together a patch that keeps GRAPH_TABLE ( on the opening line,
MATCH on one line, and COLUMNS on another,
and applied the same style to the other GRAPH_TABLE examples
in ddl.sgml and queries.sgml for consistency, for example:

SELECT customer_name FROM GRAPH_TABLE (myshop
MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date)
COLUMNS (c.name AS customer_name));

Separately, I noticed the relational query below the first GRAPH_TABLE example
in ddl.sgml is also quite long (about 150 characters).
I wonder if it's worth breaking that one too, maybe right before WHERE, like:

SELECT customers.name FROM customers JOIN customer_orders USING (customer_id) JOIN orders USING (order_id)
WHERE orders.ordered_when = current_date;

I wasn't sure whether this should be part of the same patch,
so I've attached two versions: v3 leaves it untouched,
and v4 includes the change. Let me know which you'd prefer.

Regards,
Taiki Koshino

Taiki Koshino<koshino(at)sraoss(dot)co(dot)jp>
SRA OSS K.K.
TEL: 03-5979-2701 FAX: 03-5979-2702
URL: https://www.sraoss.co.jp/

________________________________

On Tue, Aug 25, 2026 at 10:33 AM Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp> wrote:
> I put together a v2 patch that follows the approach you suggested:
> keeping GRAPH_TABLE ( on the opening line, moving the whole MATCH
> clause to its own line, and putting COLUMNS on another line, for example:
>
> SELECT customer_name FROM GRAPH_TABLE (myshop
> MATCH (c IS customers)
> -[IS customer_orders]->
> (o IS orders WHERE o.ordered_when = current_date)
> COLUMNS (c.name AS customer_name));

Splitting the path pattern across three lines is really necessary?
Even without doing that, the full MATCH line would still be around
90–100 characters, which seems readable enough.

There is another nearby GRAPH_TABLE example in queries.sgml that
uses a different formatting style. If this patch is also intended to
establish a clearer formatting style for GRAPH_TABLE examples,
isn't it better to adjust that example as well?

Regards,

--
Fujii Masao

Attachment Content-Type Size
v4-0001-doc-Reformat-SELECT-queries-using-GRAPH_TABLE.patch application/octet-stream 4.9 KB
v3-0001-doc-Reformat-SELECT-queries-using-GRAPH_TABLE.patch application/octet-stream 4.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-08-26 01:44:55 Re: Correct some doc items due to the REPACK
Previous Message Chao Li 2026-08-26 01:12:42 Re: pg_plan_advice: fix empty FOREIGN_JOIN sublist validation