Thread: Add Boolean node

This patch adds a new node type Boolean, to go alongside the "value" 
nodes Integer, Float, String, etc.  This seems appropriate given that 
Boolean values are a fundamental part of the system and are used a lot.

Before, SQL-level Boolean constants were represented by a string with
a cast, and internal Boolean values in DDL commands were usually 
represented by Integer nodes.  This takes the place of both of these 
uses, making the intent clearer and having some amount of type safety.

On Mon, Dec 27, 2021 at 5:09 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut <peter.eisentraut@enterprisedb.com> napsal:
>>
>> This patch adds a new node type Boolean, to go alongside the "value"
>> nodes Integer, Float, String, etc.  This seems appropriate given that
>> Boolean values are a fundamental part of the system and are used a lot.
>>
>> Before, SQL-level Boolean constants were represented by a string with
>> a cast, and internal Boolean values in DDL commands were usually
>> represented by Integer nodes.  This takes the place of both of these
>> uses, making the intent clearer and having some amount of type safety.
>
> +1

+1 too, looks like a good improvement.  The patch looks good to me,
although it's missing comment updates for at least nodeTokenType() and
nodeRead().

That looks like a good change. I wonder what motivates that now? Why
wasn't it added when the usages grew? Are there more Boolean usages
planned?

I ask because this code change will affect ability to automatically
cherry-pick some of the patches.

defGetBoolean() - please update the comment in the default to case to
mention defGetString along with opt_boolean_or_string production.
Reading the existing code in that function, one would wonder why to
use true and false over say on and off. But true/false seems a natural
choice. So that's fine.

defGetBoolean() and nodeRead() could use a common function to parse a
boolean string. The code in nodeRead() seems to assume that any string
starting with "t" will represent value true. Is that right?

We are using literal constants "true"/"false"  at many places. This
patch adds another one. I am wondering whether it makes sense to add
#define TRUE_STR, FALSE_STR and use it everywhere for consistency and
correctness.

For the sake of consistency (again :)), we should have a function to
return string representation of a Boolean node and use it in both
defGetString and _outBoolean().

Are the expected output changes like below necessary? Might affect
backward compatibility for applications.
-bool
-----
-t
+?column?
+--------
+t

On Mon, Dec 27, 2021 at 2:32 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
>
> This patch adds a new node type Boolean, to go alongside the "value"
> nodes Integer, Float, String, etc.  This seems appropriate given that
> Boolean values are a fundamental part of the system and are used a lot.
>
> Before, SQL-level Boolean constants were represented by a string with
> a cast, and internal Boolean values in DDL commands were usually
> represented by Integer nodes.  This takes the place of both of these
> uses, making the intent clearer and having some amount of type safety.



-- 
Best Wishes,
Ashutosh Bapat

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
> That looks like a good change. I wonder what motivates that now? Why
> wasn't it added when the usages grew?

You'd have to find some of the original Berkeley people to get an
answer for that.  Possibly it's got something to do with the fact
that C didn't have a separate bool type back then ... or, going
even further back, that LISP didn't either.  In any case, it seems
like a plausible improvement now.

Didn't really read the patch in any detail, but I did have one idea:
I think that the different things-that-used-to-be-Value-nodes ought to
use different field names, say ival, rval, bval, sval not just "val".
That makes it more likely that you'd catch any code that is doing the
wrong thing and not going through one of the access macros.

            regards, tom lane

On 2021-Dec-27, Peter Eisentraut wrote:

> This patch adds a new node type Boolean, to go alongside the "value" nodes
> Integer, Float, String, etc.  This seems appropriate given that Boolean
> values are a fundamental part of the system and are used a lot.

I like the idea.  I'm surprised that there is no notational savings in
the patch, however.

> diff --git a/src/test/regress/expected/create_function_3.out b/src/test/regress/expected/create_function_3.out
> index 3a4fd45147..e0c4bee893 100644
> --- a/src/test/regress/expected/create_function_3.out
> +++ b/src/test/regress/expected/create_function_3.out
> @@ -403,7 +403,7 @@ SELECT pg_get_functiondef('functest_S_13'::regproc);
>    LANGUAGE sql                                            +
>   BEGIN ATOMIC                                             +
>    SELECT 1;                                               +
> -  SELECT false AS bool;                                   +
> +  SELECT false;                                           +
>   END                                                      +

Hmm, interesting side-effect: we no longer assign a column name in this
case so it remains "?column?", just like it happens for other datatypes.
This seems okay to me.  (This is also what causes the changes in the
isolationtester expected output.)

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"Ni aún el genio muy grande llegaría muy lejos
si tuviera que sacarlo todo de su propio interior" (Goethe)

On 27.12.21 14:15, Ashutosh Bapat wrote:
> That looks like a good change. I wonder what motivates that now? Why
> wasn't it added when the usages grew? Are there more Boolean usages
> planned?

Mainly, I was looking at Integer/makeInteger() and noticed that most 
uses of those weren't actually integers but booleans.  This change makes 
it clearer which is which.

po 27. 12. 2021 v 16:10 odesílatel Alvaro Herrera
<alvherre@alvh.no-ip.org> napsal:
>
> On 2021-Dec-27, Peter Eisentraut wrote:
>
> > This patch adds a new node type Boolean, to go alongside the "value" nodes
> > Integer, Float, String, etc.  This seems appropriate given that Boolean
> > values are a fundamental part of the system and are used a lot.
>
> I like the idea.  I'm surprised that there is no notational savings in
> the patch, however.
>
> > diff --git a/src/test/regress/expected/create_function_3.out b/src/test/regress/expected/create_function_3.out
> > index 3a4fd45147..e0c4bee893 100644
> > --- a/src/test/regress/expected/create_function_3.out
> > +++ b/src/test/regress/expected/create_function_3.out
> > @@ -403,7 +403,7 @@ SELECT pg_get_functiondef('functest_S_13'::regproc);
> >    LANGUAGE sql                                            +
> >   BEGIN ATOMIC                                             +
> >    SELECT 1;                                               +
> > -  SELECT false AS bool;                                   +
> > +  SELECT false;                                           +
> >   END                                                      +
>
> Hmm, interesting side-effect: we no longer assign a column name in this
> case so it remains "?column?", just like it happens for other datatypes.
> This seems okay to me.  (This is also what causes the changes in the
> isolationtester expected output.)

This seems to be caused by a change of makeBoolAConst function. I was
thinking for a while about the potential backward compatibility
problems, but I wasn't able to find any.

> --
> Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
> "Ni aún el genio muy grande llegaría muy lejos
> si tuviera que sacarlo todo de su propio interior" (Goethe)
>
>

=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= <josef.simanek@gmail.com> writes:
> po 27. 12. 2021 v 16:10 odesílatel Alvaro Herrera
> <alvherre@alvh.no-ip.org> napsal:
>> Hmm, interesting side-effect: we no longer assign a column name in this
>> case so it remains "?column?", just like it happens for other datatypes.
>> This seems okay to me.  (This is also what causes the changes in the
>> isolationtester expected output.)

> This seems to be caused by a change of makeBoolAConst function. I was
> thinking for a while about the potential backward compatibility
> problems, but I wasn't able to find any.

In theory this could break some application that's expecting
"SELECT ..., true, ..." to return a column name of "bool"
rather than "?column?".  The risk of that being a problem in
practice seems rather low, though.  It certainly seems like a
wart that you get a type name for that but not for other sorts
of literals such as 1 or 2.4, so I'm okay with the change.

            regards, tom lane

On 2021-12-27 09:53:32 -0500, Tom Lane wrote:
> Didn't really read the patch in any detail, but I did have one idea:
> I think that the different things-that-used-to-be-Value-nodes ought to
> use different field names, say ival, rval, bval, sval not just "val".
> That makes it more likely that you'd catch any code that is doing the
> wrong thing and not going through one of the access macros.

If we go around changing all these places, it might be worth to also change
Integer to be a int64 instead of an int.

Andres Freund <andres@anarazel.de> writes:
> If we go around changing all these places, it might be worth to also change
> Integer to be a int64 instead of an int.

Meh ... that would have some non-obvious consequences, I think,
at least if you tried to make the grammar make use of the extra
width (it'd change the type resolution behavior for integer-ish
literals).  I think it's better to keep it as plain int.

            regards, tom lane

Hi,

On 2021-12-27 10:02:14 +0100, Peter Eisentraut wrote:
> This patch adds a new node type Boolean, to go alongside the "value" nodes
> Integer, Float, String, etc.  This seems appropriate given that Boolean
> values are a fundamental part of the system and are used a lot.
> 
> Before, SQL-level Boolean constants were represented by a string with
> a cast, and internal Boolean values in DDL commands were usually represented
> by Integer nodes.  This takes the place of both of these uses, making the
> intent clearer and having some amount of type safety.

This annoyed me plenty of times before, plus many.


> From 4e1ef56b5443fa11d981eb6e407dfc7c244dc60e Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut <peter@eisentraut.org>
> Date: Mon, 27 Dec 2021 09:52:05 +0100
> Subject: [PATCH v1] Add Boolean node
> 
> Before, SQL-level boolean constants were represented by a string with
> a cast, and internal Boolean values in DDL commands were usually
> represented by Integer nodes.  This takes the place of both of these
> uses, making the intent clearer and having some amount of type safety.
> ---
> ...
>  20 files changed, 210 insertions(+), 126 deletions(-)

This might be easier to review if there were one patch adding the Boolean
type, and then a separate one converting users?


> diff --git a/src/backend/commands/tsearchcmds.c b/src/backend/commands/tsearchcmds.c
> index c47a05d10d..b7261a88d4 100644
> --- a/src/backend/commands/tsearchcmds.c
> +++ b/src/backend/commands/tsearchcmds.c
> @@ -1742,6 +1742,15 @@ buildDefItem(const char *name, const char *val, bool was_quoted)
>              return makeDefElem(pstrdup(name),
>                                 (Node *) makeFloat(pstrdup(val)),
>                                 -1);
> +
> +        if (strcmp(val, "true") == 0)
> +            return makeDefElem(pstrdup(name),
> +                               (Node *) makeBoolean(true),
> +                               -1);
> +        if (strcmp(val, "false") == 0)
> +            return makeDefElem(pstrdup(name),
> +                               (Node *) makeBoolean(false),
> +                               -1);
>      }
>      /* Just make it a string */
>      return makeDefElem(pstrdup(name),

Hm. defGetBoolean() interprets "true", "false", "on", "off" as booleans. ISTM
we shouldn't invent different behaviours for individual subsystems?


> --- a/src/backend/nodes/outfuncs.c
> +++ b/src/backend/nodes/outfuncs.c
> @@ -3433,6 +3433,12 @@ _outFloat(StringInfo str, const Float *node)
>      appendStringInfoString(str, node->val);
>  }
>  
> +static void
> +_outBoolean(StringInfo str, const Boolean *node)
> +{
> +    appendStringInfoString(str, node->val ? "true" : "false");
> +}

Any reason not to use 't' and 'f' instead? It seems unnecessary to bloat the
node output by the longer strings, and it makes parsing more expensive
too:

> --- a/src/backend/nodes/read.c
> +++ b/src/backend/nodes/read.c
> @@ -283,6 +283,8 @@ nodeTokenType(const char *token, int length)
>          retval = RIGHT_PAREN;
>      else if (*token == '{')
>          retval = LEFT_BRACE;
> +    else if (strcmp(token, "true") == 0 || strcmp(token, "false") == 0)
> +        retval = T_Boolean;
>      else if (*token == '"' && length > 1 && token[length - 1] == '"')
>          retval = T_String;
>      else if (*token == 'b')

Before this could be implemented as a jump table, not now it can't easily be
anymore.


> diff --git a/src/test/isolation/expected/ri-trigger.out b/src/test/isolation/expected/ri-trigger.out
> index 842df80a90..db85618bef 100644
> --- a/src/test/isolation/expected/ri-trigger.out
> +++ b/src/test/isolation/expected/ri-trigger.out
> @@ -4,9 +4,9 @@ starting permutation: wxry1 c1 r2 wyrx2 c2
>  step wxry1: INSERT INTO child (parent_id) VALUES (0);
>  step c1: COMMIT;
>  step r2: SELECT TRUE;
> -bool
> -----
> -t   
> +?column?
> +--------
> +t       
>  (1 row)

This doesn't seem great. It might be more consistent ("SELECT 1" doesn't end
up with 'integer' as column name), but this still seems like an unnecessarily
large user-visible change for an internal data-representation change?

Greetings,

Andres Freund

On 29.12.21 21:32, Andres Freund wrote:
> On 2021-12-27 09:53:32 -0500, Tom Lane wrote:
>> Didn't really read the patch in any detail, but I did have one idea:
>> I think that the different things-that-used-to-be-Value-nodes ought to
>> use different field names, say ival, rval, bval, sval not just "val".
>> That makes it more likely that you'd catch any code that is doing the
>> wrong thing and not going through one of the access macros.
> 
> If we go around changing all these places, it might be worth to also change
> Integer to be a int64 instead of an int.

I was actually looking into that, when I realized that most uses of 
Integer were actually Booleans.  Hence the current patch to clear those 
fake Integers out of the way.  I haven't gotten to analyze the int64 
question any further, but it should be easier hereafter.

On 27.12.21 10:02, Peter Eisentraut wrote:
> This patch adds a new node type Boolean, to go alongside the "value" 
> nodes Integer, Float, String, etc.  This seems appropriate given that 
> Boolean values are a fundamental part of the system and are used a lot.
> 
> Before, SQL-level Boolean constants were represented by a string with
> a cast, and internal Boolean values in DDL commands were usually 
> represented by Integer nodes.  This takes the place of both of these 
> uses, making the intent clearer and having some amount of type safety.

Here is an update of this patch set based on the feedback.  First, I 
added a patch that makes some changes in AlterRole() that my original 
patch might have broken or at least made more confusing.  Unlike in 
CreateRole(), we use three-valued logic here, so that a variable like 
issuper would have 0 = no, 1 = yes, -1 = not specified, keep previous 
value.  I'm simplifying this, by instead using the dissuper etc. 
variables to track whether a setting was specified.  This makes 
everything a bit simpler and makes the subsequent patch easier.

Second, I added the suggest by Tom Lane to rename to fields in the 
used-to-be-Value nodes to be different in each node type (ival, fval, 
etc.).  I agree that this makes things a bit cleaner and reduces the 
changes of mixups.

And third, the original patch that introduces the Boolean node with some 
small changes based on the feedback.

On 03.01.22 12:04, Peter Eisentraut wrote:
> On 27.12.21 10:02, Peter Eisentraut wrote:
>> This patch adds a new node type Boolean, to go alongside the "value" 
>> nodes Integer, Float, String, etc.  This seems appropriate given that 
>> Boolean values are a fundamental part of the system and are used a lot.
>>
>> Before, SQL-level Boolean constants were represented by a string with
>> a cast, and internal Boolean values in DDL commands were usually 
>> represented by Integer nodes.  This takes the place of both of these 
>> uses, making the intent clearer and having some amount of type safety.
> 
> Here is an update of this patch set based on the feedback.  First, I 
> added a patch that makes some changes in AlterRole() that my original 
> patch might have broken or at least made more confusing.  Unlike in 
> CreateRole(), we use three-valued logic here, so that a variable like 
> issuper would have 0 = no, 1 = yes, -1 = not specified, keep previous 
> value.  I'm simplifying this, by instead using the dissuper etc. 
> variables to track whether a setting was specified.  This makes 
> everything a bit simpler and makes the subsequent patch easier.
> 
> Second, I added the suggest by Tom Lane to rename to fields in the 
> used-to-be-Value nodes to be different in each node type (ival, fval, 
> etc.).  I agree that this makes things a bit cleaner and reduces the 
> changes of mixups.
> 
> And third, the original patch that introduces the Boolean node with some 
> small changes based on the feedback.

Another very small update, attempting to appease the cfbot.

On 13.01.22 10:48, Pavel Stehule wrote:
> There are not objection from me or from community
> 
> I'll mark this patch as ready for committer

This patch set has been committed.