From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Andre Rothe <phosco(at)gmx(dot)de>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Wrong column default values |
Date: | 2009-09-19 22:18:16 |
Message-ID: | 6489.1253398696@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Kris Jurka <books(at)ejurka(dot)com> writes:
>> On Fri, 18 Sep 2009, Tom Lane wrote:
>>> Indeed. In 8.3 it seems that even if you try to set the default that
>>> way, the system will throw away the cast:
>> That's only true without a typmod.
> Hmm, maybe that could use improvement.
I looked at this a bit and found that AddRelationNewConstraints
will throw away a plain null Const default, but what it's actually
seeing in these cases is an invocation of the type's length coercion
function on a null Const. We could possibly add more code to throw
that away too (probably conditionally on the length coercion function
being strict, else it might have processing to do for a null). It
doesn't really seem worth it though. I think the OP's problem is
most elegantly solved by not writing "default null" in the first place.
It's certainly the only solution that he's likely to see payback from
in less than a year's time ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2009-09-20 10:08:23 | Re: OOM on large SELECT |
Previous Message | Tom Lane | 2009-09-19 18:52:39 | Re: Wrong column default values |