pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedERROR: PlaceHolderVar found where not expected
5+ messages / 2 participants
[nested] [flat]
Commits from this thread:
2023-03-14 684ffac8c7 3b45944430 7c509f7e5a Remove unnecessary code in dependency_is_compatible_expression().
* ERROR: PlaceHolderVar found where not expected
@ 2023-03-14 03:01 Richard Guo <guofenglinux@gmail.com>
2023-03-14 03:32 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Richard Guo @ 2023-03-14 03:01 UTC (permalink / raw)
To: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
I came across an ERROR as $subject with query below.
create table t (a int, b int);
create statistics if not exists t_s0 (dependencies, ndistinct) on a, b from
t;
insert into t values(1,1);
analyze t;
SELECT * FROM t LEFT JOIN (select true as c0) s0 ON true INNER JOIN (select
true as c0) s1 ON s0.c0 INNER JOIN (select true as c0) s2 ON s0.c0;
This is due to that we use 0 flags for pull_var_clause in
dependency_is_compatible_expression, assuming that the 'clause_expr'
cannot contain Aggrefs, WindowFuncs or PlaceHolderVars. This should be
an oversight as we can see that it's possible to find PHVs here. We can
fix it by
inline patch 1: src/backend/statistics/dependencies.c (+0/-0 lines) download inline-1.patch
--- a/src/backend/statistics/dependencies.c
+++ b/src/backend/statistics/dependencies.c
@@ -1316,7 +1316,7 @@ dependency_is_compatible_expression(Node *clause,
* Re: ERROR: PlaceHolderVar found where not expected
2023-03-14 03:01 ERROR: PlaceHolderVar found where not expected Richard Guo <guofenglinux@gmail.com>
@ 2023-03-14 03:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-03-14 03:39 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2023-03-14 03:32 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Tomas Vondra <tomas.vondra@enterprisedb.com>
Richard Guo <guofenglinux@gmail.com> writes:
> I came across an ERROR as $subject with query below.
> ...
> This is due to that we use 0 flags for pull_var_clause in
> dependency_is_compatible_expression, assuming that the 'clause_expr'
> cannot contain Aggrefs, WindowFuncs or PlaceHolderVars. This should be
> an oversight as we can see that it's possible to find PHVs here.
Nice catch.
> But I'm not sure if Aggrefs and WindowFuncs are possible to be found
> here.
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.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: ERROR: PlaceHolderVar found where not expected
2023-03-14 03:01 ERROR: PlaceHolderVar found where not expected Richard Guo <guofenglinux@gmail.com>
2023-03-14 03:32 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
@ 2023-03-14 03:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-03-14 06:08 ` Re: ERROR: PlaceHolderVar found where not expected Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2023-03-14 03:39 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: Richard Guo <guofenglinux@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: ERROR: PlaceHolderVar found where not expected
2023-03-14 03:01 ERROR: PlaceHolderVar found where not expected Richard Guo <guofenglinux@gmail.com>
2023-03-14 03:32 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
2023-03-14 03:39 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
@ 2023-03-14 06:08 ` Richard Guo <guofenglinux@gmail.com>
2023-03-14 15:11 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Richard Guo @ 2023-03-14 06:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Tue, Mar 14, 2023 at 11:39 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Yes agreed. The pull_var_clause precheck is not necessary considering
we would match the 'clause_expr' to StatisticExtInfo expressions with
equal(). +1 to remove it.
Thanks
Richard
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: ERROR: PlaceHolderVar found where not expected
2023-03-14 03:01 ERROR: PlaceHolderVar found where not expected Richard Guo <guofenglinux@gmail.com>
2023-03-14 03:32 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
2023-03-14 03:39 ` Re: ERROR: PlaceHolderVar found where not expected Tom Lane <tgl@sss.pgh.pa.us>
2023-03-14 06:08 ` Re: ERROR: PlaceHolderVar found where not expected Richard Guo <guofenglinux@gmail.com>
@ 2023-03-14 15:11 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2023-03-14 15:11 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Richard Guo <guofenglinux@gmail.com> writes:
> Yes agreed. The pull_var_clause precheck is not necessary considering
> we would match the 'clause_expr' to StatisticExtInfo expressions with
> equal(). +1 to remove it.
Done that way.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2023-03-14 15:11 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-03-14 03:01 ERROR: PlaceHolderVar found where not expected Richard Guo <guofenglinux@gmail.com>
2023-03-14 03:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-03-14 03:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-03-14 06:08 ` Richard Guo <guofenglinux@gmail.com>
2023-03-14 15:11 ` Tom Lane <tgl@sss.pgh.pa.us>
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