Justin Pryzby <pry...@telsasoft.com> writes: > ts=# begin; UPDATE eric_enodeb_201707 SET > (pmhdelayvarbest50pct,pmlicconnecteduserstimecong)=(0,0) ; > BEGIN > UPDATE 3 > ts=# begin; UPDATE eric_enodeb_201707 SET (pmhdelayvarbest50pct)=(0) ; > BEGIN > ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or > ROW() expression
Hm. It's kind of unfortunate that this isn't backwards-compatible, but it was only accidental that that case was accepted before. It's really wrong, because the source for a parenthesized UPDATE target list ought to be a row value even when there's only one item in the list. That is, the correct standards-compliant spelling would be UPDATE eric_enodeb_201707 SET (pmhdelayvarbest50pct) = ROW(0); Now, it's true that "(1,2)" is fully equivalent to "ROW(1,2)", but "(0)" is *not* equivalent to "ROW(0)"; it's just a scalar 0. So your existing code is non-spec-compliant and was really being accepted in error. We could maybe hack up some weird action-at-a-distance kluge that would make this case work like before, but I'm afraid it would just introduce other inconsistencies. > It may be that our use was wrong (?) or unintuitive (I'm in the middle of > changing it), but wondered if it was intentional or otherwise if the release > notes should mention that old syntax is no longer accepted. Not sure if it's worth getting into in the release notes. Using the parenthesis notation for single target columns seems rather weird. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers