Re: How to handle bogus nulls from ActiveRecord

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.

In response to

Responses

Browse pgsql-general by date

  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