Re: How to handle bogus nulls from ActiveRecord - Mailing list pgsql-general

From David Johnston
Subject Re: How to handle bogus nulls from ActiveRecord
Date
Msg-id 000c01cc10c3$4c38f4d0$e4aade70$@yahoo.com
Whole thread Raw
In response to How to handle bogus nulls from ActiveRecord  ("James B. Byrne" <byrnejb@harte-lyne.ca>)
Responses Re: How to handle bogus nulls from ActiveRecord  ("James B. Byrne" <byrnejb@harte-lyne.ca>)
List pgsql-general
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of James B. Byrne
> Sent: Thursday, May 12, 2011 9:12 AM
> To: pgsql-general@postgresql.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.


pgsql-general by date:

Previous
From: "Bob Pawley"
Date:
Subject: Postgredac Dump
Next
From: "James B. Byrne"
Date:
Subject: Re: How to handle bogus nulls from ActiveRecord