Re: Allow specifying NULL default in pg_proc.dat for "any" arguments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allow specifying NULL default in pg_proc.dat for "any" arguments
Date: 2026-03-06 16:01:33
Message-ID: 299555.1772812893@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florin Irion 2026-03-06 16:10:33 Re: UPDATE run check constraints for affected columns only
Previous Message Xuneng Zhou 2026-03-06 15:52:38 Re: Add pg_stat_recovery system view