From: | Sergiy Vyshnevetskiy <serg(at)vostok(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2948: default null values for not-null domains |
Date: | 2007-02-01 13:23:30 |
Message-ID: | Pine.LNX.4.64.0702011341320.22446@uanet.vostok.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, 31 Jan 2007, Tom Lane wrote:
> Sergiy Vyshnevetskiy <serg(at)vostok(dot)net> writes:
>> 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).
>
> That may be, but I'm unwilling to pay the overhead for *every* variable
> when most of them won't be domains. I'm inclined to extend PLpgSQL_type
> to include a domain indicator and only do it the hard way when we have to.
Why not add PLPGSQL_TTYPE_DOMAIN and rename PLPGSQL_TTYPE_SCALAR to
PLPGSQL_TTYPE_BASE? We only use PLPGSQL_TTYPE_SCALAR in _3_ places!
> [ looks at code... ] Actually, I think we already have the flag we
> need: look to see if the typinput function is strict.
All domains have domain_in as input function - it is NOT strict.
Anyway, as we assign a value to a domain variable we must check
constraints - that's the whole point of domains. Even when the value is
"null".
Hack attached. Any reasons not to call it a bugfix?
Attachment | Content-Type | Size |
---|---|---|
patch-pl_comp.c | text/x-csrc | 1.1 KB |
patch-pl_exec.c | text/x-csrc | 500 bytes |
patch-plpgsql.h | text/x-chdr | 471 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-02-01 14:33:48 | Re: BUG #2948: default null values for not-null domains |
Previous Message | michael | 2007-02-01 12:00:25 | BUG #2953: index scan, feature request |