Re: pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled
Date
Msg-id Y0ZOXb8bMcM0mDC7@paquier.xyz
Whole thread Raw
In response to Re: pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, Aug 10, 2022 at 09:48:08AM -0400, Tom Lane wrote:
> What I'm inclined to do, rather than repeat the same finicky &
> undocumented coding pattern in one more place, is write a convenience
> function for it that can be named and documented to reflect the coding
> rule about which call sites should use it (rather than calling plain
> generate_relation_name).  However, the first requirement for that
> is to have a clearly defined rule.  I think the intent of 815172ba8068
> was to convert all uses that would determine the object-creation schema
> in commands issued by pg_dump.  Do we want to widen that, and if so
> by how much?  I'd be on board I think with adjusting other ruleutils.c
> functions that could plausibly be used for building creation commands,
> but happen not to be called by pg_dump.  I'm not on board with
> converting every single generate_relation_name call --- mainly because
> it'd be pointless unless you also qualify every single function name,
> operator name, etc; and that would be unreadable.

Lukas, please note that this patch is waiting for your input for a few
weeks now.  Could you reply to the reviews provided?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Fix alter subscription concurrency errors
Next
From: Michael Paquier
Date:
Subject: Re: Fix gin index cost estimation