| 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: | Whole Thread | Raw Message | 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 |