Re: Possible bug: SQL function parameter in window frame definition
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alastair McKinley <a.mckinley@analyticsengines.com>,
"pgsql-general\@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Date: 2019-09-30T05:37:48Z
Lists: pgsql-hackers, pgsql-general
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: >> Here is a draft patch along those lines; the intent of this one is >> that no existing walker or mutator should need to change (the change >> to the dependency code is basically cosmetic I believe, just avoids >> walking some things twice). Tom> Hmm. I think this is a reasonable direction to go in, but Tom> what about groupingSets and rowMarks? groupingSets ultimately contains nothing but numbers which are meaningless without reference to the matching groupClause list. So anything that cares about those is really going to have to process them in its Query case in the walker function in order to get at both clauses. Similarly, rowMarks contains indexes into the rangetable (and no recursive substructure at all), so it's likewise better processed at the Query level. Tom> Also, in HEAD I'd be inclined to add assertions about utilityStmt Tom> being NULL. Yup. -- Andrew (irc:RhodiumToad)
Commits
-
Selectively include window frames in expression walks/mutates.
- 3473f81dd2a3 9.4.25 landed
- d2427f11b28d 9.5.20 landed
- 6db0d7f35917 9.6.16 landed
- ede0ab6ccce4 10.11 landed
- 0a445f27909a 11.6 landed
- 0b11dc01922b 12.1 landed
- b7a1c5539ad3 13.0 landed