From: | Sascha Kuhl <yogidabanli(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add Boolean node |
Date: | 2021-12-27 11:13:57 |
Message-ID: | CAPvVvKBCwUPzqpeHcknj_Y6QFgEpdvQuqBYC=4MkRcEPTDeadQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 should 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.
>
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
>>>>>
>>>>>
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-12-27 11:18:18 | Re: Allow escape in application_name |
Previous Message | Pavel Stehule | 2021-12-27 10:48:31 | Re: Add Boolean node |