Re: typedef struct WindowClause misleading comments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: typedef struct WindowClause misleading comments
Date: 2026-06-12 16:15:32
Message-ID: 1641996.1781280932@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 10 Jun 2026 at 04:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> +1. There are also other comments about query jumbling in nodes/*.h that
>> seem pretty information-free now. They might have been helpful before
>> we invented query_jumble_ignore and related annotations, but now they
>> seem just duplicative.

> Here's a patch for that. I did leave a few comments which mention a
> reason why a particular field is ignored. That seems like it could be
> useful. I think I've got all the ones that just talk about what's
> included or ignored.

All these changes look good, but I have a few more suggestions,
attached as a delta on top of yours. Notably

* - query_jumble_location: Mark the field as a location to track. This is
- * only allowed for integer fields that include "location" in their name.
+ * only used for fields of type ParseLoc, which otherwise are not jumbled.

If you look at how gen_node_support.pl implements that annotation,
my revised statement is correct about the field type, and I don't
see anything that actually constrains the field name to be "location".
Maybe some earlier implementation behaved that way?

regards, tom lane

Attachment Content-Type Size
cleanup_query_jumble_comments.patch text/x-diff 4.8 KB
cleanup_query_jumble_comments_tgl.patch text/x-diff 4.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-06-12 16:59:14 Modernizing pg_bsd_indent's error/warning reporting code
Previous Message Peter Geoghegan 2026-06-12 16:10:39 Re: s/pg_attribute_always_inline/pg_always_inline/?