From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: The output sql generated by pg_dump for a create function refers to a modified table name |
Date: | 2023-02-17 20:46:31 |
Message-ID: | 2769963.1676666791@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jonathan S. Katz" <jkatz(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-17 20:50:09 | Re: Move defaults toward ICU in 16? |
Previous Message | Jeff Davis | 2023-02-17 20:43:47 | Re: Move defaults toward ICU in 16? |