On Thu, 1 Feb 2007, Tom Lane wrote:
Sergiy Vyshnevetskiy <[EMAIL PROTECTED]> writes:
Why not add PLPGSQL_TTYPE_DOMAIN and rename PLPGSQL_TTYPE_SCALAR to
PLPGSQL_TTYPE_BASE? We only use PLPGSQL_TTYPE_SCALAR in _3_ places!
That was my first thought too, but it's wrong. The right thing is to
look at the strictness of the input function, because that is the API
we have defined to determine whether a datatype might possibly be
interested in rejecting nulls. The fact that domain_in() is the only
example in the core system doesn't make it correct to restrict the
functionality to domains.
...
I have been slow.
If input function IS strict then nulls are ALWAYS accepted.
If input function IS NOT strict then nulls MIGHT be rejectted.
And the patch is much more simple now (attached).
Is that it?
--- src/pl/plpgsql/src/pl_exec.c.orig Wed Oct 4 03:30:13 2006
+++ src/pl/plpgsql/src/pl_exec.c Thu Feb 1 20:05:01 2007
@@ -844,6 +844,11 @@
{
var->value = (Datum) 0;
var->isnull = true;
+ if(!var->datatype->typinput.fn_strict)
+ {
+ exec_assign_value(estate, (PLpgSQL_datum *) var,
+ 0, UNKNOWNOID, &(var->isnull));
+ }
if (var->notnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
