Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 18.04.21 23:33, Tom Lane wrote:
>> The actual use-case for that seems pretty thin, so we never bothered
>> to worry about it before. But if we're going to build loop-breaking
>> logic to handle function body dependencies, it should deal with this
>> too. I think that all that's required is for the initial dummy
>> function declaration to omit defaults as well as providing a dummy
>> body.
> I have studied this a bit. I'm not sure where the dummy function
> declaration should be created. The current dependency-breaking logic in
> pg_dump_sort.c doesn't appear to support injecting additional objects
> into the set of dumpable objects. So we would need to create it perhaps
> in dumpFunc() and then later set flags that indicate whether it will be
> required.
Hmm, good point. The existing code that breaks loops involving views
depends on the fact that the view relation and the view's ON SELECT
rule are already treated as distinct objects within pg_dump. So we
just need to mark the rule object to indicate whether to emit it or
not. To make it work for functions, there would have to be a secondary
object representing the function body (and the default expressions,
I guess).
That's kind of a lot of complication, and inefficiency, for a corner case
that may never arise in practice. We've ignored the risk for default
expressions, and AFAIR have yet to receive any field complaints about it.
So maybe it's okay to do the same for SQL-style function bodies, at least
for now.
> Another option would be that we disallow this at creation time.
Don't like that one much. The backend shouldn't be in the business
of rejecting valid commands just because pg_dump might be unable
to cope later.
regards, tom lane
