On 10/17/14 5:03 PM, Merlin Moncure wrote:
Hm, I didn't understand your objection:
<quoting>
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.
</quoting>
That's not correct: it should work exactly as 'select' does; given a
conflict resolve the field name, so no backwards compatibility issue.
local:marko=# show server_version;
server_version
----------------
9.1.13
(1 row)
local:marko=#* create table foo(f int);
CREATE TABLE
local:marko=#* update foo f set f=1;
UPDATE 0
This query would change meaning with your suggestion.
I'm not saying it would be a massive problem in practice, but I think we
should first consider options which don't break backwards compatibility,
even if some consider them "less clean".
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
