Re: How to handle bogus nulls from ActiveRecord
От | David Johnston |
---|---|
Тема | Re: How to handle bogus nulls from ActiveRecord |
Дата | |
Msg-id | 000c01cc10c3$4c38f4d0$e4aade70$@yahoo.com обсуждение исходный текст |
Ответ на | How to handle bogus nulls from ActiveRecord ("James B. Byrne" <byrnejb@harte-lyne.ca>) |
Ответы |
Re: How to handle bogus nulls from ActiveRecord
|
Список | 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 по дате отправления: