Re: BUG #2948: default null values for not-null domains
От | Sergiy Vyshnevetskiy |
---|---|
Тема | Re: BUG #2948: default null values for not-null domains |
Дата | |
Msg-id | Pine.LNX.4.64.0701312042210.22446@uanet.vostok.net обсуждение исходный текст |
Ответ на | Re: BUG #2948: default null values for not-null domains (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #2948: default null values for not-null domains
|
Список | pgsql-bugs |
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. :)
В списке pgsql-bugs по дате отправления: