Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"
Дата
Msg-id 87muw0tfml.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-bugs
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >>> On PostgreSQL 11 Beta, I exec sql like "update
 >>> fvt_obj_operate_update_table_033 set (c_int) = (20) where c_int = 20;",
 >>> which only on column to set, got ""ERROR:  source for a multiple-column
 >>> UPDATE item must be a sub-SELECT or ROW() expression"".

 Tom> It's telling you what to do: use a ROW() expression, ie

 Tom> update fvt_obj_operate_update_table_033 set (c_int) = row(20)
 Tom> where c_int = 20;

 Andrew> Yeah, but (a) this used to work, and has worked since at least
 Andrew> as far back as 9.0, and (b) the spec requires it to work.

Looking at the previous discussion, in fact, it seems that you were
under the misapprehension that the spec requires the use of ROW there;
it does not. So this is actually broken in pg 10.

Here is the expansion with references according to sql2016 (leaving out
all the irrelevant bits):

14.15 <set clause list>

<multiple column assignment> ::=
   <set target list> <equals operator> <assigned row>

<assigned row> ::=
   <contextually typed row value expression>

7.2 <row value expression>

<contextually typed row value expression> ::=
    <contextually typed row value constructor>

7.1 <row value constructor>

<contextually typed row value constructor> ::=
       <common value expression>

6.28 <value expression>

<common value expression> ::=
       <numeric value expression>

<numeric value expression> ::= [snipped for brevity]

<numeric primary> ::=
       <value expression primary>

6.3 <value expression primary>

<value expression primary> ::=
       <parenthesized value expression>

(I'll stop here since (20) is obviously a <parenthesized value expression>)

At this point, we go back up the stack to 7.1 <row value constructor>,
where we find this syntax rule:

5) Let CTRVC be the <contextually typed row value constructor>.
   a) If CTRVC is a <common value expression>, <boolean value expression>,
      or <contextually typed value specification> X, then CTRVC is
      equivalent to:

         ROW ( X )

So by the time we get back to syntax rule 4 of 14.15 <set clause list>,
the <assigned row> term is not (20) but ROW( (20) ), and the expansion
into individual columns succeeds.

Another obvious way to see that ROW isn't required here by the spec is
to notice that INSERT ... VALUES (20); also doesn't need ROW, and that's
using the same syntax (specifically, <contextually typed row
value constructor> is used in both cases).

-- 
Andrew (irc:RhodiumToad)


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15238: Sequence owner not updated when owning table is foreign