Re: Possible bug: SQL function parameter in window frame definition

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Alastair McKinley <a(dot)mckinley(at)analyticsengines(dot)com>, "pgsql-general\(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Possible bug: SQL function parameter in window frame definition
Date: 2019-09-29 18:15:31
Message-ID: 28299.1569780931@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Andrew" == Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> Andrew> We could minimize the chance of breakage in a back-patched fix
> Andrew> by having query_tree_walker/mutator iterate the windowClause
> Andrew> list itself

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

Hmm. I think this is a reasonable direction to go in, but
what about groupingSets and rowMarks?

Also, in HEAD I'd be inclined to add assertions about utilityStmt
being NULL.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message stan 2019-09-29 19:40:20 Thoughts on a cosntraint ?
Previous Message Andrew Gierth 2019-09-29 10:46:49 Re: Possible bug: SQL function parameter in window frame definition

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2019-09-29 19:31:25 Re: Unstable select_parallel regression output in 12rc1
Previous Message Tomas Vondra 2019-09-29 17:56:30 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions