Re: Possible bug: SQL function parameter in window frame definition
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-10-02T15:32:51Z
Lists: pgsql-hackers, pgsql-general
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Tom> Also, in HEAD I'd be inclined to add assertions about utilityStmt > Tom> being NULL. > Tried this. The assertion is hit: > ... > Any suggestions where best to fix this? transformRuleStmt could be > taught to skip a lot of the per-Query stuff it does in the event that > the Query is actually a NOTIFY, or a check for NOTIFY could be added > further down the stack, e.g. in rangeTableEntry_used. Any preferences? Hm. transformRuleStmt already does special-case utility statements to some extent, so my inclination would be to make it do more of that. However, it looks like that might end up with rather spaghetti-ish code, as that function is kind of messy already. Or we could abandon the notion of adding the assertion. I don't know how much work it's worth. regards, tom lane
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