• Tom Lane's avatar
    Improve handling of "UPDATE ... SET (column_list) = row_constructor". · 906bfcad
    Tom Lane authored
    Previously, the right-hand side of a multiple-column assignment, if it
    wasn't a sub-SELECT, had to be a simple parenthesized expression list,
    because gram.y was responsible for "bursting" the construct into
    independent column assignments.  This had the minor defect that you
    couldn't write ROW (though you should be able to, since the standard says
    this is a row constructor), and the rather larger defect that unlike other
    uses of row constructors, we would not expand a "foo.*" item into multiple
    columns.
    
    Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
    it to transformMultiAssignRef to separate the elements of a RowExpr;
    which it will do only after performing standard transformation of the
    RowExpr, so that "foo.*" behaves as expected.
    
    The key reason we didn't do that before was the hard-wired handling of
    DEFAULT tokens (SetToDefault nodes).  This patch deals with that issue by
    allowing DEFAULT in any a_expr and having parse analysis throw an error
    if SetToDefault is found in an unexpected place.  That's an improvement
    anyway since the error can be more specific than just "syntax error".
    
    The SQL standard suggests that the RHS could be any a_expr yielding a
    suitable row value.  This patch doesn't really move the goal posts in that
    respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
    fix the grammar restriction, so it provides some tangible progress towards
    a full implementation.  And the limitation is now documented by an explicit
    error message rather than an unhelpful "syntax error".
    
    Discussion: <8542.1479742008@sss.pgh.pa.us>
    906bfcad
parse_target.c 52 KB