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.
Hi
po 3. 1. 2022 v 14:18 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
>
> 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, Stri
NodeTag type;
- int val;
+ int ival;
} Integer;
/*
@@ -45,24 +45,24 @@ typedef struct Integer
typedef struct Float
{
NodeTag type;
- char *val;
+ char *fval;
} Float;
typedef struct String
{
er;
/*
@@ -45,24 +45,24 @@ typedef struct Integer
typedef struct Float
{
NodeTag type;
- char *val;
+ char *fval;
} Float;
typedef struct String
{
NodeTag type;
- char *val;
+ char *sval;
} String;
typedef
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".
.
This annoyed me plenty of times before, plus many.
> From 4e1ef56b5443fa11d981eb6e407dfc7c244dc60e Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Mon, 27 Dec 2021 09:52:05 +0100
> Subject: [PATCH v1] Add Boolean node
>
> Before, SQL-level boolean constants were
Andres Freund 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 typ
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'
=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> po 27. 12. 2021 v 16:10 odesílatel Alvaro Herrera
> 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 wh
po 27. 12. 2021 v 16:10 odesílatel Alvaro Herrera
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 th
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 integer
Hi,
For buildDefItem():
+ if (strcmp(val, "true") == 0)
+ return makeDefElem(pstrdup(name),
+ (Node *) makeBoolean(true),
+ -1);
+ if (strcmp(val, "false") == 0)
Should 'TRUE' / 'FALSE' be considered above ?
-
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 the
Ashutosh Bapat 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 b
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
po 27. 12. 2021 v 13:05 odesílatel Sascha Kuhl
napsal:
>
>
> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
> 12:28:
>
>>
>>
>> po 27. 12. 2021 v 12:23 odesílatel Sascha Kuhl
>> napsal:
>>
>>>
>>>
>>> Sascha Kuhl schrieb am Mo., 27. Dez. 2021,
>>> 12:13:
>>>
Pavel Stehule schrieb
Pavel Stehule schrieb am Mo., 27. Dez. 2021,
12:28:
>
>
> po 27. 12. 2021 v 12:23 odesílatel Sascha Kuhl
> napsal:
>
>>
>>
>> Sascha Kuhl schrieb am Mo., 27. Dez. 2021, 12:13:
>>
>>>
>>>
>>> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
>>> 11:49:
>>>
Hi
po 27. 12. 2021 v 11:24 o
po 27. 12. 2021 v 12:23 odesílatel Sascha Kuhl
napsal:
>
>
> Sascha Kuhl schrieb am Mo., 27. Dez. 2021, 12:13:
>
>>
>>
>> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
>> 11:49:
>>
>>> Hi
>>>
>>> po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
>>> napsal:
>>>
You think, all values are valid
Sascha Kuhl schrieb am Mo., 27. Dez. 2021, 12:13:
>
>
> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
> 11:49:
>
>> Hi
>>
>> po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
>> napsal:
>>
>>> You think, all values are valid. Is a higher german order valid for
>>> Turkey, that only know baskets, as
Pavel Stehule schrieb am Mo., 27. Dez. 2021,
11:49:
> Hi
>
> po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
> napsal:
>
>> You think, all values are valid. Is a higher german order valid for
>> Turkey, that only know baskets, as a Form of order. For me not all forms of
>> all are valid for all.
Hi
po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
napsal:
> You think, all values are valid. Is a higher german order valid for
> Turkey, that only know baskets, as a Form of order. For me not all forms of
> all are valid for all. You cannot Export or Import food that You dislike,
> because it w
You think, all values are valid. Is a higher german order valid for Turkey,
that only know baskets, as a Form of order. For me not all forms of all are
valid for all. You cannot Export or Import food that You dislike, because
it would hurt you. Do you have dishes that you dislike? Is all valid for
On Mon, Dec 27, 2021 at 5:09 PM Pavel Stehule wrote:
>
> po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut
> 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 funda
po 27. 12. 2021 v 11:08 odesílatel Sascha Kuhl
napsal:
> Can that boolean node be cultural dependent validation for the value? By
> the developer? By all?
>
why?
The boolean node is not a boolean type.
This is an internal feature. There should not be any cultural dependency
Regards
Pavel
>
Can that boolean node be cultural dependent validation for the value? By
the developer? By all?
Pavel Stehule schrieb am Mo., 27. Dez. 2021,
10:09:
>
>
> po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> napsal:
>
>>
>> This patch adds a new node type Boo
po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut <
peter.eisentr...@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 an
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
27 matches
Mail list logo
