Re: BUG #19034: Recursive function with sql_body can replace an existing function but can not be created on it's own

On Sun, Sep 7, 2025, 14:09 Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:

> On Fri, 2025-09-05 at 05:55 -0700, David G. Johnston wrote:
> > > Sure, but creating a dump that will fail to load is not good.
> > > I don't have a smarter idea that dumping standard SQL functions
> > > in two statements like you suggested...
> >
> > When resolving the dependency graph for such a function can we prevent
> the
> > oid of the parent and the oid of the child being the same value?
> > Prohibit direct self-references so it fails even if you use “or replace”.
>
> I am not sure I can follow. With "parent" and "child", do you mean the
> function as it was originally created and the function after replacing
> it with a recursive function? If yes, then that's not an option.
> The main point of CREATE OR REPLACE FUNCTION is to preserve the oid.
>

Right, because the oid is preserved when the create or replace finishes
pg_depend must have an entry where objid = refobjid where the oid value is
that of the originally created function that is now just being altered.
That situation seems detectable and prohibit-able.

refobjid is generically the parent, objid is generically the child.
Dropping parents requires cascade which is how the "normal" type describes
the refobjid. (Given that here they are the same I suppose parent/child is
needlessly confusing - I should have looked at the columns names the first
time.)

David J.