I'm looking at implementing IS DISTINCT FROM, among other things. It has
the unusual behavior that it compares elements for a tuple by
considering two NULLs to be equal (hence non-distinct) rather than
"unknown". So the rules for comparison seem to be:
a) if the rows compared have different lengths, they are distinct
b) if the rows are both zero-length, they are not distinct
c) otherwise, each element in the row (or a single value on each side of
the comparison) are compared pairwise, with
1) if both elements are NULL, they are not distinct
2) if one element of the pair is NULL, they are distinct
3) if both elements are NOT NULL and are equal, they are not distinct
4) if no pair of elements is distinct, the rows are not distinct
5) otherwise, the rows are distinct
I was thinking to implement this by simply expanding these rules within
gram.y to be a tree of comparison tests. But I think that this does not
generalize properly into allowing tuples or rows to be supplied by
subqueries or other non-literal tuples. So, I'm looking for suggestions
on how to go about implementing this. Should I define a new comparison
node like the AND expression which can directly handle the NULL
behaviors correctly? That would require at least minor changes in the
optimizer and executor. Does another approach come to mind (esp. one
which works ;)?
TIA
- Thomas
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
