From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
cc: Richard Guo <guofenglinux@gmail.com>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: ERROR: PlaceHolderVar found where not expected
In-reply-to: <2474960.1678764751@sss.pgh.pa.us>
References: 
 <CAMbWs48Mmvm-acGevXuwpB=g5JMqVSL6i9z5UaJyLGJqa-XPAA@mail.gmail.com>
 <2474960.1678764751@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 13 Mar 2023 23:32:31 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2475646.1678765184.1@sss.pgh.pa.us>
Date: Mon, 13 Mar 2023 23:39:44 -0400
Message-ID: <2475647.1678765184@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2475647.1678765184%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> WindowFuncs should be disallowed in qual clauses, so I think it's okay
> to leave those flags out.  An Aggref could occur in a HAVING qual though.
> I'm not sure if this code could get applied to HAVING ... but it's
> not immediately clear that it can't.  I'd be inclined to add
> PVC_RECURSE_AGGREGATES, as that seems more likely to be okay than not.

Actually, on closer look: why don't we just nuke that pull_var_clause
call entirely, along with the following loop inspecting its result?

The subsequent loop that looks for a matching StatisticExtInfo
expression will do just fine at rejecting any expression that
contains Vars of the wrong relation.  Maybe there is some performance
argument why the pull_var_clause precheck is worth the trouble,
but I'm inclined to bet that it's actually a net loss.

			regards, tom lane