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

  1. Selectively include window frames in expression walks/mutates.