postgres_fdw: Handle boolean comparison predicates

Hi Emre,
This looks like a good improvement.

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.

Mean time here are some comments.
+/*
+ * Deparse IS [NOT] TRUE/FALSE/UNKNOWN expression.
+ */
+static void
+deparseBooleanTest(BooleanTest *node, deparse_expr_cxt *context)
+{
+    StringInfo    buf = context->buf;
+
+    switch (node->booltesttype)
+    {

+        case IS_NOT_TRUE:
+            appendStringInfoString(buf, "(NOT ");
+            deparseExpr(node->arg, context);
+            appendStringInfoString(buf, " OR ");
+            deparseExpr(node->arg, context);
+            appendStringInfoString(buf, " IS NULL)");
+            break;

+}

I don't understand why we need to complicate the expressions when
sending those to the foreign nodes. Why do we want to send (xyz IS
FALSE) (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.

+EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE (c1 = 100) IS
TRUE; -- BooleanTest

Also test a boolean column?

On Mon, May 31, 2021 at 1:33 PM Emre Hasegeli <emre@hasegeli.com> wrote:

The comparison predicates IS [NOT] TRUE/FALSE/UNKNOWN were not
recognised by postgres_fdw, so they were not pushed down to the remote
server. The attached patch adds support for them.

I am adding this to the commitfest 2021-07.

--
Best Wishes,
Ashutosh Bapat

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]https://commitfest.postgresql.org/33/3144/. 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.

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

[1]: https://commitfest.postgresql.org/33/3144/

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

The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation: not tested

Hello

I tried to apply the patch to master branch and got a couple of errors, so I think the patch needs a rebase.

I also agree with Ashutosh that the "IS NOT TRUE" case can be simplified to just "IS FALSE". it's simpler to understand.

based on this, I think we should restructure the switch-case statement in deparseBooleanTest because some of the cases in there evaluate to the same result but handles differently.

For example, "IS TRUE" and "IS NOT FALSE" both evaluate to true, so can be handled in the same way

something like:
switch (node->booltesttype)
{
case IS_TRUE:
case IS_NOT_FALSE:
appendStringInfoChar(buf, '(');
deparseExpr(node->arg, context);
appendStringInfoString(buf, ")");
break;
case IS_FALSE:
case IS_NOT_TRUE:
appendStringInfoChar(buf, '(');
deparseExpr(node->arg, context);
appendStringInfoString(buf, " IS FALSE)");
break;
case IS_UNKNOWN:
appendStringInfoChar(buf, '(');
deparseExpr(node->arg, context);
appendStringInfoString(buf, " IS NULL)");
break;
case IS_NOT_UNKNOWN:
appendStringInfoChar(buf, '(');
deparseExpr(node->arg, context);
appendStringInfoString(buf, " IS NOT NULL)");
break;
}

just a thought
thanks!

-------------------------------
Cary Huang
HighGo Software Canada
www.highgo.ca

Cary Huang <cary.huang@highgo.ca> writes:

I also agree with Ashutosh that the "IS NOT TRUE" case can be simplified to just "IS FALSE". it's simpler to understand.

Uh ... surely that's just wrong?

regression=# select null is not true;
?column?
----------
t
(1 row)

regression=# select null is false;
?column?
----------
f
(1 row)

regards, tom lane

On 31 May 2021, at 18:51, Emre Hasegeli <emre@hasegeli.com> wrote:

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

The patch no longer applies to HEAD, can you please submit a rebased version?

--
Daniel Gustafsson https://vmware.com/

On 1 Sep 2021, at 13:15, Daniel Gustafsson <daniel@yesql.se> wrote:

On 31 May 2021, at 18:51, Emre Hasegeli <emre@hasegeli.com> wrote:

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

The patch no longer applies to HEAD, can you please submit a rebased version?

Since the commitfest is now ending, I'm marking this Returned with Feedback.
Please resubmit a rebased version for the next CF if you are still interested
in pursuing this patch.

--
Daniel Gustafsson https://vmware.com/