Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM' - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'
Date
Msg-id CAFj8pRBh6poiBzodqXPTjCn3sqOvJj1TwdrLsrgw6TyK2oQ-kw@mail.gmail.com
Whole thread Raw
In response to Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'  (Eugen Konkov <kes-kes@yandex.ru>)
Responses Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'
List pgsql-hackers


po 28. 10. 2019 v 12:39 odesílatel Eugen Konkov <kes-kes@yandex.ru> napsal:
>         x IS NOT DISTINCT FROM y

> I'm vaguely imagining

>         x = {magic} y

> where unlike Eugen's suggestion, "=" is the real name of the underlying
> comparison operator.  For dump/restore this could be spelled verbosely
> as

>         x OPERATOR(someplace.=) {magic} y

> The hard part is to figure out some {magic} annotation that is both
> short and unambiguous.  We have to cover the IS DISTINCT variant, too.

I  am  from  Perl  world.  There  are  == and != operators.
Here short snippet of code:

my $x = undef;
my $y = 'some value';
my $z = undef;
$x == $y; # FALSE
$x == $z; # TRUE
$x != $y ; # TRUE
$x != $z;  # FALSE


>         x OPERATOR(someplace.=) {magic} y
If we should follow this form, then IS DISTINCT should be written as:
x =! y
This  looks unusual, because JavaScript also follow != form. so I hope
it  will be easy to detect/implement != form, which I used to read as:
negate the result of comparison



Can   we   supply   additional   parameters  to  OPERATOR  via  double
parentheses( double parentheses is another crazy idea)?
x =(( 'NULL' )) y

It's looks much more terrible than original IS DISTINCT FROM


or

x OPERATOR(someplace.=, magic ) y
which   will  be  internally  converted(  I  suppose  )  to  OPERATOR(
someplace.=, x, y, magic )

I don't think so benefit of this is too valuable against possible problems.

MySQL has special operator <=>, so if we implement some, then we should to implement this. But better do nothing. I don't see significant benefit of this against costs.

Pavel

--
Best regards,
Eugen Konkov



pgsql-hackers by date:

Previous
From: Surafel Temesgen
Date:
Subject: Re: WIP: System Versioned Temporal Table
Next
From: Peter Eisentraut
Date:
Subject: Preserve versions of initdb-created collations in pg_upgrade