From: Tom Lane <tgl@sss.pgh.pa.us>
To: eric.cyr@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18202: pg_constraint data isn't refreshed when using alter
 rename to on a constraint trigger
In-reply-to: <18202-0783b23955b5d2fd@postgresql.org>
References: <18202-0783b23955b5d2fd@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 17 Nov 2023 14:31:35 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <564632.1700234243.1@sss.pgh.pa.us>
Date: Fri, 17 Nov 2023 10:17:23 -0500
Message-ID: <564633.1700234243@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/564633.1700234243%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> When we rename a constraint trigger it seems like the name is not updated in
> pg_constraint.

Hmm, yeah ... renametrig() is intent on renaming the entry in pg_trigger,
but I see no code there that pays any attention to pg_constraint.
Conversely, ALTER TABLE RENAME CONSTRAINT updates the pg_constraint
entry but not the associated trigger.  It's not real clear to me
whether this is intentional.  There's no a-priori reason why the
two objects have to have the same name; but I doubt we have pg_dump
support for recreating a situation where they are different.
[ experiments ... ] Interestingly, pg_dump seems to dump the name
from pg_trigger not the one from pg_constraint.

			regards, tom lane