Re: PostgreSQL 10 parenthesized single-column updates can produce errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rob McColl <rob(at)robmccoll(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostgreSQL 10 parenthesized single-column updates can produce errors
Date: 2017-10-31 22:43:59
Message-ID: 30606.1509489839@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rob McColl <rob(at)robmccoll(dot)com> writes:
> Attaching patch... :-/

The reason why hacking your way to a backwards-compatible solution is
a bad idea is that it breaks the SQL standard compliance we're trying to
achieve here. According to the spec, the elements of a parenthesized
SET list should be assigned from the fields of a composite RHS. If
there's just one element of the SET list, the RHS should be a single-field
composite value, and this syntax should result in extracting its field.
This patch doesn't do that; it preserves our previous broken behavior,
and thus just puts off the day of reckoning that inevitably will come.

As a concrete example, the spec says this should work:

create table t (f1 int);
update t set (f1) = row(4);

and it does in v10, but (without having tested) your patch will break it.
This is not so exciting for simple row constructors, where you could just
leave off the word ROW; but it is a critical distinction if we're ever to
get to the point of allowing other composite-returning constructs here,
for example composite-returning functions.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2017-10-31 22:44:36 Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM
Previous Message Gilles Darold 2017-10-31 22:36:53 Re: proposal: schema variables