On Wed, 31 Jan 2007, Tom Lane wrote:
> Sergiy Vyshnevetskiy <serg@vostok.net> 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. :)