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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Yushu Chen <gentcys(at)gmail(dot)com>
Cc: katja(dot)henke(at)foo(dot)ag, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19034: Recursive function with sql_body can replace an existing function but can not be created on it's own
Date: 2025-09-04 15:24:58
Message-ID: 1030106.1756999498@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Yushu Chen <gentcys(at)gmail(dot)com> writes:
> I ran a test on my local postgresql server, resulting in the same error as
> described.
> However, I wonder about the necessity of supporting recursive functions in
> the CREATE FUNCTION command alone?

This is a general property of SQL-standard functions: all objects
referenced in the function body have to exist before creating the
function. Poking holes in that property would largely defeat the
point of having this type of function.

You could imagine supporting the case by making CREATE FUNCTION act
as though it were
CREATE FUNCTION foo ... AS $$something dummy$$;
CREATE OR REPLACE FUNCTION foo ... BEGIN real-body END;
However, that would be a significant amount of work to implement
and it'd about double the cost of doing CREATE FUNCTION. Note
that this cost would probably have to be incurred for every
SQL-standard function, as I see no good way to detect whether
the body contains a recursive reference in advance of parsing it.

Given that recursive SQL functions are a tiny-minority use case
and there's already a perfectly serviceable way to make them
(ie use an old-style body), I seriously doubt that we'll do
anything about this request.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-09-05 02:28:45 RE: BUG #19041: Logical replication locks wal processing
Previous Message Greg Sabino Mullane 2025-09-04 12:56:05 Re: empty,query_id, pg_stat_activity