From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, emre(at)hasegeli(dot)com |
Subject: | Re: postgres_fdw: Handle boolean comparison predicates |
Date: | 2021-07-22 07:40:30 |
Message-ID: | 8440061.GEkzpLcyQo@aivenronan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le lundi 31 mai 2021, 18:51:57 CEST Emre Hasegeli a écrit :
> > Please add this patch to the commitfest so that it's not forgotten. It
> > will be considered as a new feature so will be considered for commit
> > after the next commitfest.
>
> I did [1]. You can add yourself as a reviewer.
>
> > I don't understand why we need to complicate the expressions when
> > sending those to the foreign nodes. Why do we want to send
> > (NOT xyz OR xyz IS NULL) and not as just (xyz IS FALSE).
> > The latter is much more readable and less error-prone. That true for
> > all the BooleanTest deparsing.
>
> = true/false conditions are normalised. I thought similar behaviour
> would be expected here.
I agree with Ashutosh, since IS NOT TRUE / FALSE is already a way of
normalizing it I don't really see what this brings.
>
> > +EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE (c1 = 100) IS
> > TRUE; -- BooleanTest
> >
> > Also test a boolean column?
>
> There isn't a boolean column on the test table currently.
We should probably add one then.
--
Ronan Dunklau
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-07-22 07:44:54 | Re: ORDER BY pushdowns seem broken in postgres_fdw |
Previous Message | David Rowley | 2021-07-22 07:38:50 | Re: Add proper planner support for ORDER BY / DISTINCT aggregates |