Re: doc: Reformat SELECT queries using GRAPH_TABLE

> I agree that spreading this query over multiple lines would be better
> but the way it's done in the patch doesn't feel right. It leaves the
> first vertex pattern on the original line along with GRAPH_TABLE and
> MATCH. The rest of the path pattern is moved to the next line. This
> make it hard to grasp the whole path pattern in one go. I think we
> should try leaving GRAPH_TABLE ( ... on the original line and move the
> whole MATCH clause to the next line and COLUMNS to another line.
> However the path pattern would still be long enough that it would
> require scrolling. But we should try that first.
>
> If we break the path pattern into multiple lines, the problem there is
> whether to keep the arrows or connecting lines along with the vertex
> or with the edge. Since the standard defines an edge pattern as the
> arrow/connector along with the brackets, it might be better to keep
> the arrows and connectors with the edge pattern. Formatting the query
> as below might be better.
>
> 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));
>
> But with that one has to read multiple lines to understand the path
> pattern. So I would avoid it for a small pattern like this.

Hi,

Thanks for the detailed feedback.
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));

I've confirmed that with this formatting,
each line stays short enough that
horizontal scrolling is unlikely to be needed,
while the path pattern is still easy to read as a whole.

I applied the same formatting consistently to both occurrences
in ddl.sgml and the one in queries.sgml. Attached is the v2 patch.
Let me know if this matches what you had in mind,
or if you would prefer a different line break for the path pattern.

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 Fri, Aug 21, 2026 at 12:35 PM Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp> wrote:
>
> Hi,
>
> The SELECT queries using GRAPH_TABLE in ddl.sgml and queries.sgml
> were written on single long lines, requiring horizontal scrolling.
>
> This patch breaks the queries across multiple lines to improve
> readability. This is also consistent with the CREATE PROPERTY GRAPH
> statement in the PostgreSQL documentation, which is already formatted
> across multiple lines:

I agree that spreading this query over multiple lines would be better
but the way it's done in the patch doesn't feel right. It leaves the
first vertex pattern on the original line along with GRAPH_TABLE and
MATCH. The rest of the path pattern is moved to the next line. This
make it hard to grasp the whole path pattern in one go. I think we
should try leaving GRAPH_TABLE ( ... on the original line and move the
whole MATCH clause to the next line and COLUMNS to another line.
However the path pattern would still be long enough that it would
require scrolling. But we should try that first.

If we break the path pattern into multiple lines, the problem there is
whether to keep the arrows or connecting lines along with the vertex
or with the edge. Since the standard defines an edge pattern as the
arrow/connector along with the brackets, it might be better to keep
the arrows and connectors with the edge pattern. Formatting the query
as below might be better.

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));

But with that one has to read multiple lines to understand the path
pattern. So I would avoid it for a small pattern like this.

--
Best Wishes,
Ashutosh Bapat