Hi,
On 2026-02-16 12:31:37 -0500, Andrew Dunstan wrote:
> Motivated by Bug 19409 [1] I decided to do something about a wart that has
> bugged me for a while, namely the requirement to write stuff in
> system_views.sql if you need to specify default values for function
> arguments.
I'm one more person this has been bugging.
A related issue is that we have grants and revokes as part of
system_functions.sql. Perhaps it's worth tackling that at the same time?
> Here's my attempt. The first patch here sets up the required
> infrastructure. genbki.pl creates a file called function_defaults.sql which
> is run by initdb at the appropriate time.
Hm. I don't love that we first insert something into pg_proc, then generate a
full blown CREATE OR REPLACE FUNCTION with all the details to edit it. It
wouldn't take too much to somehow end up, down the line, with a silent
mismatch between what pg_proc.h contains and what CREATE OR REPLACE FUNCTION
ends up generating. I'm not sure we'd be likely to notice such a mismatch
immediately.
In fact, I think the current translation may have such an issue, the generated
CREATE OR REPLACE doesn't seem include ROWS, which seems to lead to resetting
prorows to the default 1000, regardless of what it was before.
DROP FUNCTION IF EXISTS foo();
CREATE FUNCTION foo() RETURNS SETOF int LANGUAGE SQL VOLATILE ROWS 10 AS $$SELECT generate_series(1, 10)$$;
SELECT prorows FROM pg_proc WHERE proname = 'foo';
┌─────────┐
│ prorows │
├─────────┤
│ 10 │
└─────────┘
CREATE OR REPLACE FUNCTION foo() RETURNS SETOF int LANGUAGE SQL VOLATILE AS $$SELECT generate_series(1, 10)$$;
SELECT prorows FROM pg_proc WHERE proname = 'foo';
┌─────────┐
│ prorows │
├─────────┤
│ 1000 │
└─────────┘
I wish we could just generate the parse-analyzed representation for default
values during bootstrap, but that's probably not realistic.
Although, I guess we don't really need the full machinery. Afaict we just need
a list of simple CONST nodes. There are two current functions (random_normal()
and pg_terminate_backend()), where the default expressions contains casts
implemented via FUNCEXPR, but that's just sloppiness in the DEFAULT
specification we probably should fix independently of everything else.
Greetings,
Andres Freund
