Re: Allow specifying NULL default in pg_proc.dat for "any" arguments
| От | Andrew Dunstan |
|---|---|
| Тема | Re: Allow specifying NULL default in pg_proc.dat for "any" arguments |
| Дата | |
| Msg-id | f11dc6f6-e461-45a1-a7de-781273fcc21d@dunslane.net обсуждение исходный текст |
| Ответ на | Re: Allow specifying NULL default in pg_proc.dat for "any" arguments (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Allow specifying NULL default in pg_proc.dat for "any" arguments
|
| Список | pgsql-hackers |
On 2026-03-06 Fr 11:01 AM, Tom Lane wrote:
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
В списке pgsql-hackers по дате отправления: