From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Tim Starling <tstarling(at)wikimedia(dot)org>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Upsert error "column reference is ambiguous" |
Date: | 2025-04-29 14:51:58 |
Message-ID: | 1026716.1745938318@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Another thought is that you can have an UPDATE with a RETURNING
> clause. An unqualified column defaults to NEW even though you could
> argue it's ambiguous due to OLD (as of 80feb727c). Likely we were
> forced into making it work that way through not wanting to force
> everyone to rewrite their RETURNING statements when upgrading to v18.
> The moral of that story is, UPDATE isn't exactly consistent already
> about when it requires column qualifications. Maybe it's weird to
> insist that users qualify columns with their ON CONFLICT UPDATE SET
> when RETURNING is happy to assume you must have meant NEW.
That's an analogy I hadn't thought of, and it does seem on-point.
You might be right that we would not have done it like that if
we'd invented RETURNING's ability to support "OLD" at the get-go.
Nonetheless, it's there now and is a pretty similar precedent.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-04-29 15:29:28 | Re: Upsert error "column reference is ambiguous" |
Previous Message | Dominique Devienne | 2025-04-29 14:50:40 | Re: DROP ROLE as SUPERUSER |