On Tue, Oct 31, 2017 at 3:14 PM, Rob McColl <r...@robmccoll.com> wrote:
> >> I believe that this is not an intended change or behavior, but is instead >> an unintentional side effect of 906bfcad7ba7cb3863fe0e2a7810be8e3cd84fbd >> Improve handling of "UPDATE ... SET (column_list) = row_constructor". ( >> https://github.com/postgres/postgres/commit/906bfcad7ba7cb3 >> 863fe0e2a7810be8e3cd84fbd). >> > At this point the intent of 906bfcad doesn't really matter - and given the number of complaints in the month since v10 went live I'm tending to lean toward bringing the pre-10 behavior back. There is no ambiguity involved here and the breakage of existing applications seems considerably worse than the technical oddity of allowing (val) to be interpreted as a row_constructor in this situation. From a standards perspective we are strictly more permissive so no new problem there. On a related note, the 10.0 syntax guide is wrong, it needs to break out the parenthesized single-column and multi-column variants separately: Presently: ( column_name [, ...] ) = [ ROW ] ( { expression | DEFAULT } [, ...] ) Basically one cannot specify only a single column_name AND omit ROW It would have been nice if the syntax for that variant would have been: ( column_name, column_name [, ...] ) = [ ROW ] ( { expression | DEFAULT }, { expression | DEFAULT } [, ...] ) If the v10 behavior remains the above change should be made as well as adding: ( column_name ) = ROW ( expression | DEFAULT ) If we revert 10 to the pre-10 behavior the existing syntax will work. David J.
