Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 2020-08-12 21:54, Robert Haas wrote:
>> One problem with this, which I think Tom pointed out before, is that
>> it might make it to handle some forward-compatibility problems. In
>> other words, if something that the server is generating needs to be
>> modified for compatibility with a future release, it's not easy to do
>> that. Like if we needed to quote something we weren't previously
>> quoting, for example.
> We already use a lot of other pg_get_*def functions in pg_dump. Does
> this one introduce any fundamentally new problems?
I wouldn't say that it's *fundamentally* new, but nonethless it disturbs
me that this proposal has pg_dump assembling CREATE FUNCTION commands in
very different ways depending on the server version. I'd rather see us
continuing to build the bulk of the command the same as before, and
introduce new behavior only for deparsing the function body.
We've talked before about what a mess it is that some aspects of pg_dump's
output are built on the basis of what pg_dump sees in its stable snapshot
but others are built by ruleutils.c on the basis of up-to-the-minute
catalog contents. While I don't insist that this patch fix that, I'm
worried that it may be making things worse, or at least getting in the
way of ever fixing that.
Perhaps these concerns are unfounded, but I'd like to see some arguments
why before we go down this path.
regards, tom lane
