Hi,
On 2019-10-26 14:23:49 -0400, Tom Lane wrote:
> I wrote:
> > We do have some unresolved issues around how to let dump/restore
> > control the interpretation of IS [NOT] DISTINCT FROM, cf
> > https://www.postgresql.org/message-id/flat/ffefc172-a487-aa87-a0e7-472bf29735c8%40gmail.com
> > but I don't think this idea is helping with that at all.
>
> BTW, taking a step back and viewing this suggestion as "it'd be nice
> to have *some* shorter notation than IS [NOT] DISTINCT FROM", maybe
> there's a way to unify that desire with the dump/restore fix. What
> we'd really need to fix the dump/restore problem, AFAICS, is to name
> the underlying equality operator --- potentially with a schema
> qualification --- but then have some notation that says "handle NULLs
> like IS [NOT] DISTINCT FROM does". So instead of
>
> 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.
Leaving the exact choice of how {magic} would look like, are you
thinking of somehow making it work for every operator, or just for some
subset? It's intriguing to have something generic, but I'm not quite
clear how that'd would work? It's not clear to me how we'd
automatically infer a sensible meaning for e.g. < etc.
And even if we just restrict it to = (and presumably <> and !=), in
which cases is this magic going to work? Would we tie it to the textual
'=', '<>' operators? btree opclass members?
Greetings,
Andres Freund
