Adrian Klaver <[email protected]> writes: > On 8/3/26 8:17 AM, Färber, Franz-Josef (StMUK) wrote: >> But what about my other item... what about somehow preventing to write all >> column names, i. e. changing ... >> SET (col1, col2, ...) >> ... to something like ... >> SET (myTable.*)
> Best bet is you are seeing the effect of, from here: > https://www.postgresql.org/docs/18/sql-update.html The SQL standard does not allow writing "*" there, and that's a restriction I agree with. If you write "SELECT *" and the output has more or fewer columns, or columns in a different order, than you expected, no great harm is done to your database. If we allowed "UPDATE SET (*) = blah, blah" and the same type of confusion occurred, you might completely destroy your table. Writing out the target columns explicitly is a small price to reduce the odds of mistakes. (I'm too lazy to search for the exact quote, but there's something in Brooks' classic "The Mythical Man-month" to the effect that, if a fairy came to a programmer and offered to make all his code bug-free if he'd agree to type it in three times, any programmer in the world would instantly take that bargain.) Having said that, the error checks in transformMultiAssignRef could probably be ordered better. For instance: postgres=# create table tab (a int, b int); CREATE TABLE postgres=# update tab set (*) = row(1,2); ERROR: syntax error at or near "*" LINE 1: update tab set (*) = row(1,2); ^ postgres=# update tab set (tab.*) = row(1,2); ERROR: number of columns does not match number of values LINE 1: update tab set (tab.*) = row(1,2); ^ postgres=# update tab set (tab.*) = row(1); ERROR: column "tab" of relation "tab" does not exist LINE 1: update tab set (tab.*) = row(1); ^ HINT: SET target columns cannot be qualified with the relation name. We ought to be complaining that the SET target is inherently invalid before we start thinking about whether it matches the source value. regards, tom lane
