-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
>> However, you quickly run into the problem of holidays. While you >> could construct a helper table listing all the holidays, ones that >> don't fall on the same day every year (e.g. Easter) will trip >> you up. > Er, isn't Easter usually on a Sunday? I meant the same numerical date, e.g. Christmas is always December 25th, and so is a little easier programatically than the rules for Easter. If you meant that Sunday is never a business day, then yes, it was a bad example. :) > Anyway, I also found this, the first hit if you google "sql holidays": > http://www.sqlmag.com/Article/ArticleID/25899/sql_server_25899.html > > The big ugly union might need to be munged a bit, but most of the non- > weekend US holidays seem to be there. Sure, that's an alternative, but it seems a bit too much reinventing an already existing wheel. I was amused to see the script had the ill-fated Lee-Jackson-King day in it. Ideally, we'd want a Postgres table that describes the rules for each holiday, and then a function that reads it on the fly. Perhaps a project for another day... - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200704261706 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD4DBQFGMRUnvJuQZxSWSsgRAwn3AJ9o1CCb2x3Asn1U70xyphetZ6a2XgCY5fuG coAVQiUyFWqKyJWCpJBanA== =gmZi -----END PGP SIGNATURE----- ---------------------------(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
