I've committed support for IS DISTINCT FROM to the head of the CVS tree.
I did not update the catalog version, but since one enumerated type has
added a value it may be that initdb is actually required. Almost
certainly a "make clean" is essential.
There is more work to do, including perhaps adding some more internal
nodes, but initial functionality is there. I still owe some docs and
regression tests as well as further work on the implementation (per
previous discussion on The Right Way to add row features).
Details from the cvs log are below.
- Thomas
Move INTERSECT DISTINCT to the supported category. Error in docs.
Implement the IS DISTINCT FROM operator per SQL99.
Reused the Expr node to hold DISTINCT which strongly resemblesthe existing OP info. Define DISTINCT_EXPR which strongly
resemblestheexisting OPER_EXPR opType, but with handling for NULLs requiredby SQL99.
Implement the IS DISTINCT FROM operator per SQL99.
Reused the Expr node to hold DISTINCT which strongly resemblesthe existing OP info. Define DISTINCT_EXPR which strongly
resemblestheexisting OPER_EXPR opType, but with handling for NULLs requiredby SQL99.
We have explicit support for single-element DISTINCT comparisonsall the way through to the executor. But, multi-element
DISTINCTsarehandled by expanding into a comparison tree in gram.y as is done
forother row comparisons. Per discussions, it might be desirable to movethis into one or more purpose-built nodes to be
handledin the backend.
Define the optional ROW keyword and token per SQL99.This allows single-element row constructs, which were formerly
disalloweddue to shift/reduce conflicts with parenthesized a_expr clauses.
Define the SQL99 TREAT() function. Currently, use as a synonym for
CAST().