From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Richard Guo <guofenglinux@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: ERROR: PlaceHolderVar found where not expected
Date: Mon, 13 Mar 2023 23:39:44 -0400
Message-ID: <2475647.1678765184@sss.pgh.pa.us> (raw)
In-Reply-To: <2474960.1678764751@sss.pgh.pa.us>
References: <CAMbWs48Mmvm-acGevXuwpB=g5JMqVSL6i9z5UaJyLGJqa-XPAA@mail.gmail.com>
<2474960.1678764751@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, tomas.vondra@enterprisedb.com, guofenglinux@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: ERROR: PlaceHolderVar found where not expected
In-Reply-To: <2475647.1678765184@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox