Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Oct 28, 2019 at 10:07 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Of course neither of those ideas is as short as "==", but
>> I think we should put some weight on not breaking things.
>> I do not believe Robert's position that nobody will complain
>> if we break extensions' use of "==" just to save some typing.
> I mean, do we have to break the extensions? If we just added ==
> operators that behaved like IS NOT DISTINCT FROM to each datatype, why
> would anything get broken?
Is that the proposal? I certainly assumed that Eugen had in mind a
parser-level hack, because adding dozens of new operators and their
underlying functions would be a Lot Of Tedious Work. But I agree
that if we did it like that, it (probably) wouldn't break anything.
I'd be somewhat inclined to adopt "===" and "!===" as the standard
names, trading off one more keystroke to get to a point where we
almost certainly aren't conflicting with anybody's existing usage.
One objection to proceeding like that is that there'd be no
visible connection between a datatype's "=" and "===" operators,
removing any hope of someday optimizing, for example, "x IS NOT
DISTINCT FROM 42" into an indexscan on x. We're certainly not
very bright about these constructs today, but at least there
exists the possibility of doing better in future. I suppose
we could think about extending btree opclasses to allow for
an === entry, but that'd be another pile of work ...
regards, tom lane
