On Wed, Sep 14, 2005 at 00:09:58 -0400,
Joe <svn@xxxxxxxxxxxxxxxxx> wrote:
>
> I'm not sure I agree with the need to "fix" or "sanitize" the data. The
> columns in question are used mostly for publication dates. While you may
> be able to find a full release date for recent books, they are generally
> listed as published on a given year, period. Most monthly magazines only
> have a month-year of publication. And of course, daily newspapers and
> Internet articles usually have a full day-month-year. In fact, the MySQL
> solution didn't address quarterly or bi-monthly publications as that data
> was only captured as one of the months in the period--as opposed to Mar/Apr
> 2005 or First Quarter 2005 (or worse: Winter 2004). As Tom Lane argued, it
> seems I'll have to bite the bullet and create a new datatype. The only
> other alternative I see would be to split the publication date into three
> columns and that's rather ugly.
It seems like in your case the dates are best expressed as ranges and that
you could store the information you have using an earliest possible date
and a lastest possible date. If there are extra constraints based on how
far apart the begin and end dates are you could implement them as well.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
