On 18.04.21 23:33, Tom Lane wrote:
> ... BTW, a dependency loop is also possible without using this feature,
> by abusing default-value expressions:
>
> create function f1(x int, y int) returns int language sql
> as 'select $1 + $2';
> create function f2(x int, y int default f1(1,2)) returns int language sql
> as 'select $1 + $2';
> create or replace function f1(x int, y int default f2(11,12)) returns int language sql
> as 'select $1 + $2';
>
> 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.
Another option would be that we disallow this at creation time. It
seems we could detect dependency loops using findDependentObjects(), so
this might not be so difficult. The use case for recursive SQL
functions is probably low, at least with the current limited set of
control flow options in SQL. (And you can always use a quoted body to
work around it.)