Re: pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2022-Aug-09, Lukas Fittl wrote:
>> But I wonder, why do we have an explicit pretty printing flag on these
>> functions, and PRETTYFLAG_SCHEMA in the code to represent this behavior.
>> If we don't want pretty printing to affect schema qualification, why
>> does that flag exist?

> Because of CVE-2018-1058. See commit 815172ba8068.

> I imagine that that commit only touched the minimum necessary to solve
> the immediate security problem, but that further work is needed to make
> PRETTYFLAG_SCHEMA become a fully functional gadget; but that would
> require that the whole of ruleutils.c (and everything downstream from
> it) behaves sanely. In other words, I think your patch is too small.

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.

regards, tom lane