From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Supporting multiple column assignment in UPDATE (9.5 project) |
Date: | 2014-05-03 10:48:34 |
Message-ID: | 5364C982.7060003@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/2/14, 10:10 PM, Merlin Moncure wrote:
> On Fri, May 2, 2014 at 3:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Meh. Then you could have a query that works fine until you add a column
>> to the table, and it stops working. If nobody ever used column names
>> identical to table names it'd be all right, but unfortunately people
>> seem to do that a lot...
>
> That's already the case with select statements
I don't think that's true if you table-qualify your column references
and don't use SELECT *.
> and, if a user were
> concerned about that, always have the option of aliasing the table as
> nearly 100% of professional developers do:
>
> SELECT f FROM foo f;
> etc.
So e.g.:
UPDATE foo f SET f = ..;
would resolve to the table, despite there being a column called "f"?
That would break backwards compatibility.
How about:
UPDATE foo SET ROW(foo) = (1,2,3);
ISTM that this could be parsed unambiguously, though it's perhaps a bit
ugly.
Regards,
Marko Tiikkaja
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2014-05-03 13:17:38 | Re: pg_get_viewdefs() indentation considered harmful |
Previous Message | Dave Page | 2014-05-03 08:31:34 | Re: Sending out a request for more buildfarm animals? |