Re: The output sql generated by pg_dump for a create function refers to a modified table name

"Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
> I spoke too soon -- I was looking at the wrong logs. I did reproduce it
> with UPDATE, but not INSERT.

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.

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.

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.

regards, tom lane