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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-02-17T20:46:31Z
Lists: pgsql-hackers
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> 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).

I suppose you can also make examples where the true name of the DML
target table conflicts with an outer-query name, implying that we need
to give it an alias even though the user wrote none.

> 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.

Cool, thanks for testing and code-reading.  I'll go see about
back-patching.

> 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.

Presumably it can also cause dump/restore failures for rules that
do this sort of thing, though admittedly those wouldn't be common.

			regards, tom lane



Commits

  1. Print the correct aliases for DML target tables in ruleutils.