On 2/17/23 1:18 PM, Tom Lane wrote:
It can be reproduced with INSERT too, on the same principle as the others: put the DML command inside a WITH, and give it an alias conflicting with the outer query.
Ah, I see based on your example below. I did not alias the INSERT statement in the way (and I don't know how common of a pattern it is to o that).
Being a lazy sort, I tried to collapse all three cases into a single test case, and observed something I hadn't thought of: we disambiguate aliases in a WITH query with respect to the outer query, but not with respect to other WITH queries. This makes the example (see attached) a bit more confusing than I would have hoped. However, the same sort of thing happens within other kinds of nested subqueries, so I think it's probably all right as-is. In any case, changing this aspect would require a significantly bigger patch with more risk of unwanted side-effects.
I think I agree. Most people should not be looking at the disambiguated statements unless they are troubleshooting an issue (such as $SUBJECT). The main goal is to disambiguate correctly.
To fix it, I pulled out the print-an-alias logic within get_from_clause_item and called that new function for INSERT/UPDATE/DELETE. This is a bit of overkill perhaps, because only the RTE_RELATION case can be needed by these other callers, but it seemed like a sane refactorization. I've not tested, but I imagine this will need patched all the way back. The rule case should be reachable in all supported versions.
I tested this against HEAD (+v69 of the DDL replication patch). My cases are now all passing.
The code looks good to me -- I don't know if moving that logic is overkill, but it makes the solution relatively clean.
I didn't test in any back branches yet, but given this can generate an invalid function body, it does likely need to be backpatched.
Thanks, Jonathan
OpenPGP_signature
Description: OpenPGP digital signature
