Alvaro Herrera <alvhe...@alvh.no-ip.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