From 9f910a3b9aeab5a79142860eea53747c1f321aa3 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 6 Jan 2009 02:01:27 +0000 Subject: [PATCH] Add some comments about why function parameter default expressions are restricted. --- src/backend/commands/functioncmds.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/backend/commands/functioncmds.c b/src/backend/commands/functioncmds.c index 91b65b3a58..a813fd9a02 100644 --- a/src/backend/commands/functioncmds.c +++ b/src/backend/commands/functioncmds.c @@ -10,7 +10,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/commands/functioncmds.c,v 1.106 2009/01/01 17:23:38 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/commands/functioncmds.c,v 1.107 2009/01/06 02:01:27 tgl Exp $ * * DESCRIPTION * These routines take the parse tree and pick out the @@ -311,7 +311,15 @@ examine_parameter_list(List *parameters, Oid languageOid, errmsg("cannot use table references in parameter default value"))); /* + * It can't return a set either --- but coerce_to_specific_type + * already checked that for us. + * * No subplans or aggregates, either... + * + * Note: the point of these restrictions is to ensure that an + * expression that, on its face, hasn't got subplans, aggregates, + * etc cannot suddenly have them after function default arguments + * are inserted. */ if (pstate->p_hasSubLinks) ereport(ERROR, -- 2.40.0