Обсуждение: Allow specifying NULL default in pg_proc.dat for "any" arguments

I noticed a small gap in our recent addition of default arguments for 
functions in pg_proc.dat - it chokes if you try to set the default for a 
VARIADIC "any" argument. But there's no need if the default argument us 
NULL, as it often is. We don't need the argument's type_io_data etc. in 
such a case. So this patch just handles NULL without fetching any type info.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:
> I noticed a small gap in our recent addition of default arguments for 
> functions in pg_proc.dat - it chokes if you try to set the default for a 
> VARIADIC "any" argument. But there's no need if the default argument us 
> NULL, as it often is. We don't need the argument's type_io_data etc. in 
> such a case. So this patch just handles NULL without fetching any type info.

I'm not very convinced by this: the Const it produces may have
the wrong typlen, typbyval, typcollation for the declared data type.
It's possible that the incorrect typlen and typbyval markings can
never matter considering that Const.constisnull will be true, but
I'm not 100% sure of that.  More to the point, I'm pretty sure
that the incorrect typcollation *does* matter: it could lead to
invalid conclusions about the overall collation of a function call,
or bogus "inconsistent collation" errors.

If we need a TypInfo[] entry for ANY, let's just add it.
But I haven't seen any use cases?

            regards, tom lane

Andrew Dunstan <andrew@dunslane.net> writes:

I noticed a small gap in our recent addition of default arguments for 
functions in pg_proc.dat - it chokes if you try to set the default for a 
VARIADIC "any" argument. But there's no need if the default argument us 
NULL, as it often is. We don't need the argument's type_io_data etc. in 
such a case. So this patch just handles NULL without fetching any type info.

I'm not very convinced by this: the Const it produces may have
the wrong typlen, typbyval, typcollation for the declared data type.
It's possible that the incorrect typlen and typbyval markings can
never matter considering that Const.constisnull will be true, but
I'm not 100% sure of that.  More to the point, I'm pretty sure
that the incorrect typcollation *does* matter: it could lead to
invalid conclusions about the overall collation of a function call,
or bogus "inconsistent collation" errors.

If we need a TypInfo[] entry for ANY, let's just add it.
But I haven't seen any use cases?
			

Well, I guess that raises the question of what we get if we now do

CREATE OR REPLACE FUNCTION foo(x int, VARIADIC y "any" DEFAULT NULL);

which is the use case I was trying to avoid :-)

Turns out it sets the type to "unknown" and the constlen to -2.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2026-03-06 Fr 11:01 AM, Tom Lane wrote:
>> If we need a TypInfo[] entry for ANY, let's just add it.
>> But I haven't seen any use cases?

> Well, I guess that raises the question of what we get if we now do
> CREATE OR REPLACE FUNCTION foo(x int, VARIADIC y "any" DEFAULT NULL);
> which is the use case I was trying to avoid :-)
> Turns out it sets the type to "unknown" and the constlen to -2.

Hmm.  Not sure if that matters or not.  In any case, my objection
to the proposed patch was its side-effects on defaults that are of
regular data types.  I don't think we want to change that behavior.

What exactly would be the use case for a default like the above?
I can see the point of, say, trying to merge the two variants of
jsonb_build_array:

CREATE FUNCTION pg_catalog.jsonb_build_array(VARIADIC "any") ...

CREATE FUNCTION pg_catalog.jsonb_build_array() ...

but introducing a default wouldn't help us do that, because it'd
still end up looking like a 1-argument call not a no-argument call.

            regards, tom lane

On 2026-03-06 Fr 11:53 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 2026-03-06 Fr 11:01 AM, Tom Lane wrote:
>>> If we need a TypInfo[] entry for ANY, let's just add it.
>>> But I haven't seen any use cases?
>> Well, I guess that raises the question of what we get if we now do
>> CREATE OR REPLACE FUNCTION foo(x int, VARIADIC y "any" DEFAULT NULL);
>> which is the use case I was trying to avoid :-)
>> Turns out it sets the type to "unknown" and the constlen to -2.
> Hmm.  Not sure if that matters or not.  In any case, my objection
> to the proposed patch was its side-effects on defaults that are of
> regular data types.  I don't think we want to change that behavior.


Yeah. Here for posterity is a patch for that. But I won't pursue it 
because ...


>
> What exactly would be the use case for a default like the above?
> I can see the point of, say, trying to merge the two variants of
> jsonb_build_array:
>
> CREATE FUNCTION pg_catalog.jsonb_build_array(VARIADIC "any") ...
>
> CREATE FUNCTION pg_catalog.jsonb_build_array() ...
>
> but introducing a default wouldn't help us do that, because it'd
> still end up looking like a 1-argument call not a no-argument call.
>
>             


I was looking at it from the perspective of the pg_get_database_ddl 
patch. But that seems a bit baroque. I think we can make life a lot 
simpler here by using "VARIADIC options TEXT DEFAULT NULL".


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com