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
