From: | "David Johnston" <polobo(at)yahoo(dot)com> |
---|---|
To: | "'James B(dot) Byrne'" <byrnejb(at)harte-lyne(dot)ca>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How to handle bogus nulls from ActiveRecord |
Date: | 2011-05-12 16:40:26 |
Message-ID: | 000c01cc10c3$4c38f4d0$e4aade70$@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org [mailto:pgsql-general-
> owner(at)postgresql(dot)org] On Behalf Of James B. Byrne
> Sent: Thursday, May 12, 2011 9:12 AM
> To: pgsql-general(at)postgresql(dot)org
> Subject: [GENERAL] How to handle bogus nulls from ActiveRecord
>
>
> So solve this for the moment what I think I require is a trigger on
> expected_at which tests for NULL on insert and converts it to infinity.
The
> other alternative is to simply set the default to some valid, but
unreachable,
> date like 9999-12-31.
>
Not a huge fan of Infinity as a value...but that just may be lack of
experience.
I'd probably remove the NOT NULL constraint on expected_at and deal with
tri-value logic; or also include a boolean (is_expected) and form queries
like
NOT is_expected OR (is_expected AND expected_at <op> timestamp)
"is_expected" could be a calculated value in a view to make things somewhat
easier; otherwise you'd need a table constraint to ensure non-null expected
has a true is_expected.
Without more info as to how you use "expected_at" other advice is difficult
but can you user a meaningful value (say now()+'30 days'::interval) for the
default?
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | James B. Byrne | 2011-05-12 17:14:07 | Re: How to handle bogus nulls from ActiveRecord |
Previous Message | Bob Pawley | 2011-05-12 16:32:00 | Postgredac Dump |