Re: Adding support for a fully qualified column-name in UPDATE ...SET
От | Jim Finnerty |
---|---|
Тема | Re: Adding support for a fully qualified column-name in UPDATE ...SET |
Дата | |
Msg-id | 1544206695157-0.post@n3.nabble.com обсуждение исходный текст |
Ответ на | Re: Adding support for a fully qualified column-name in UPDATE ... SET (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Considering first just the addition of the table-name or correlation-name, without a schema-name qualifier: UPDATE table-name [ AS correlation-name ] SET [ { table-name | correlation-name } '.' ] column-name opt_indirection '=' value-expression ';' we take the first sql92identifier after the SET as the presumed column-name, and we create a list for the indirection elements, if any. So for the ambiguous case (t.c versus c.f), the first token must match the table-name (or correlation-name, if supplied), and the second token must be the name of a column of table t (i.e. that t.t exists), and also t.c must have a composite type. If all of these are true, we can parse this as c.f, just as we do now, so existing PostgreSQL applications would have the same semantics. if an Oracle application has an UPDATE statement written as: myTable.myTable = scalarValue when myTable is a column of myTable, and myTable.myTable has a composite type, but scalarValue is not coercible into the full composite value of that type, then you'd get an error. So, don't do that, because we will interpret the meaning of this corner case like PostgreSQL has always interpreted it. Adding the optional schema-name doesn't expand the scope of that corner case very much, although there are the usual issues with search_path. ----- Jim Finnerty, AWS, Amazon Aurora PostgreSQL -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
В списке pgsql-hackers по дате отправления: