Re: Should IS DISTINCT FROM work with ANY()?

On Jan 29, 2009, at 5:50 PM, Tom Lane wrote:

> I don't think we want it to come true. If we treat IS DISTINCT FROM
> as a weirdly-named operator then we have to provide an implementation
> for every datatype (oh, and another one for IS NOT DISTINCT FROM).
> The PITA factor is enormous. Much better to handle it the way we
> are now, where it's a specialized expression node type.
>
> To get it to work with ANY/ALL you'd probably need some special hack
> to
> create new sublink types, or something like that. Also a PITA, but
> a lot more localized ...

Okay, I don't know much about the internals, so of course it may be a
PITA, but the documentation doesn't really sound like it. Maybe the
docs need updating? For example, the documentation for ANY and SOME
says:

> expression operator ANY (array expression)
> expression operator SOME (array expression)

Which makes me think that it will work with any comparison operator.
Conveniently, IS (NOT)? DISTINCT FROM is listed on the comparison
operators page, which says:

> expression IS DISTINCT FROM expression
> expression IS NOT DISTINCT FROM expression

Since `ANY(ARRAY['foo'])` is an expression, I had expected it to work.
Furthermore, the docs for ANY and SOME say:

> For non-null inputs, IS DISTINCT FROM is the same as the <>
> operator. However, when both inputs are null it will return false,
> and when just one input is null it will return true.

Reading this, I assumed that IS DISTINCT FROM should work with any two
operands to which <> applies. Meaning the underlying function would
check for NULL values and return the proper value as appropriate, and
simply re-dispatch to the function for the <> operator if neither
operand is NULL. If that's the case, based on the docs, I'd just
expect IS DISTINCT FROM ANY() to be supported, and we just have a
parsing problem.

So maybe this isn't accurate? Should IS DISTINCT FROM *not* be
documented as a binary operator? Or maybe it should be documented that
it somehow doesn't rely on the = operator internally?

IOW, I get that you say it'd be a PITA to support this in in the code,
Tom, so maybe the docs should be updated to explain what operands IS
DISTINCT FROM can and cannot apply to?

Thanks,

David