Re: Add Boolean node

po 27. 12. 2021 v 13:05 odesílatel Sascha Kuhl <yogidabanli(at)gmail(dot)com>
napsal:

>
>
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> schrieb am Mo., 27. Dez. 2021,
> 12:28:
>
>>
>>
>> po 27. 12. 2021 v 12:23 odesílatel Sascha Kuhl <yogidabanli(at)gmail(dot)com>
>> napsal:
>>
>>>
>>>
>>> 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.
>>>
>>
>> again - Node type is not equal to data type.
>>
>
> Did you know that different culture have different trees. You read that.
> The Chinese Bonsai reflects Chinese Société, as well as the german buche
> reflects Verwaltung
>
> Thanks for the separation of node and data. If you consider keys, ie.
> Indexes trees, keys and nodes can be easily the same, in a simulation.
> Thanks for your view.
>

look at Postgres source code , please.
https://github.com/postgres/postgres/tree/master/src/backend/nodes. In this
case nodes have no relation to the index's tree.

Regards

Pavel

>> Regards
>>
>> Pavel
>>
>>