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.
