IS DISTINCT FROM and TREAT() committed
От | Thomas Lockhart |
---|---|
Тема | IS DISTINCT FROM and TREAT() committed |
Дата | |
Msg-id | 3D2469B3.2128091@fourpalms.org обсуждение исходный текст |
Список | pgsql-hackers |
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().
В списке pgsql-hackers по дате отправления: