On Wed, 31 Jan 2007, Tom Lane wrote:
Sergiy Vyshnevetskiy <[EMAIL PROTECTED]> writes:
This should fix the problem.
No, not at all. Consider if you'd written a domain CHECK constraint
that rejects nulls, instead of the easy case.
I've forgotten that.
What we'd really have to do here is see if domain_in() will accept a
NULL.
Almost correct. We need to set the default value for every variable to
null "the right way".
First, we need a PLpgSQL_expr variable for "null" expression. A static
variable assigned at program startup would be best, but on-the-fly will
work too, if slightly inefficient.
Second, we use a pointer to it instead of NULL in decl_defval in gram.y.
That's all!
What to call to convert a text string "null" into PLpgSQL_expr?
Where's the best place to call it?
I'm starting to get the feeling that the entire idea of NOT NULL domains
is broken :-(
Not at all. What's "broken" is the idea of variable as a simple piece of
memory. It is correct for base types, but not for domains - they may have
non-empty constructors (in C++ terminology).
As such, the so-called "optimized" assignment algorithm for null defaults
("let's flip a bit and pretend we've done it") in exec_stmt_block() may
not work for such domains.
Assign them all and let optimizer sort them out. :)
---------------------------(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
