Re: Add Boolean node

Sascha Kuhl <yogidabanli(at)gmail(dot)com> schrieb am Mo., 27. Dez. 2021, 12:13:

>
>
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> schrieb am Mo., 27. Dez. 2021,
> 11:49:
>
>> Hi
>>
>> po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl <yogidabanli(at)gmail(dot)com>
>> 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 would hurt you. Do you have dishes that you dislike? Is all
>>> valid for you and your culture.
>>>
>>> It is ok that this is an internal feature, that is not cultural
>>> dependent. Iwanted to give you my Interpretation of this Feature. It is ok
>>> It doesn't fit 😉
>>>
>>
>> Please, don't use top posting mode in this mailing list
>> https://en.wikipedia.org/wiki/Posting_style#Top-posting
>>
>
> I will read and learn on that. Thanks for the hint.
>
>
>> This is an internal feature - Node structures are not visible from SQL
>> level. And internal features will be faster and less complex, if we don't
>> need to implement cultural dependency there. So False is just only false,
>> and not "false" or "lez" or "nepravda" or "Marchen" any other.
>>
>> On a custom level it is a different situation. Although I am not sure if
>> it is a good idea to implement local dependency for boolean type. In Czech
>> language we have two related words for "false" - "lez" and "nepravda". And
>> nothing is used in IT. But we use Czech (German) format date (and
>> everywhere in code ISO format shou lld be preferred), and we use czech
>> sorting. In internal things less complexity is better (higher complexity
>> means lower safety) . On a custom level, anybody can do what they like.
>>
>
If you See databases as a tree, buche like books, the stem is internal,
less complexity, strong and safe. The custom level are the bows and leafs.
Ever leaf gets the ingredients it likes, but all are of the same type.

>>
>
> I agree on that from a german point of view. This is great structure on a
> first guess.
>
>
>> Regards
>>
>> Pavel
>>
>>
>>>
>>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> schrieb am Mo., 27. Dez. 2021,
>>> 11:15:
>>>
>>>>
>>>>
>>>> po 27. 12. 2021 v 11:08 odesílatel Sascha Kuhl <yogidabanli(at)gmail(dot)com>
>>>> 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
>>>>
>>>>
>>>>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> schrieb am Mo., 27. Dez.
>>>>> 2021, 10:09:
>>>>>
>>>>>>
>>>>>>
>>>>>> po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut <
>>>>>> peter(dot)eisentraut(at)enterprisedb(dot)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
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Pavel
>>>>>>
>>>>>>