Re: help: now() + N is now failing!
От | Mel Jamero |
---|---|
Тема | Re: help: now() + N is now failing! |
Дата | |
Msg-id | 000301c355ed$5823b0d0$1b06a8c0@CMPMEL обсуждение исходный текст |
Ответ на | Re: help: now() + N is now failing! (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-novice |
thanks to all you guys. now (and now() + 2), things are clearer =) tom, thank you! mel -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Tuesday, July 29, 2003 11:20 PM To: Dmitry Tkach Cc: mel@gmanmi.tv; pgsql-novice@postgresql.org Subject: Re: [NOVICE] help: now() + N is now failing! Dmitry Tkach <dmitry@openratings.com> writes: > I guess, the now()+2 has the same problem - for some reason, it fails to > coerce timestamptz into date automatically :-( > Why is that? There is only one function called date_pli(), and there is > an unambigous conversion date(timestamptz)... Why does it now force the > user to cast explicitly??? Because it's an information-losing coercion. To reduce the odds that a surprising interpretation will be chosen, we have tightened the casting rules so that only up-promotions and not down-promotions will happen implicitly within expressions. As a comparison point, you would like float8 + int4 to be done in float8 rather than int4 arithmetic, would you not? If both directions of casting are equally implicit then there's no basis for the parser to choose the preferred operator. An alternative approach for Mel to fix his problem is to change the pg_cast entry for timestamptz-to-date to allow it to happen implicitly, but (a) that might have unforeseen side effects in other contexts, and (b) it wouldn't get dumped by pg_dump, as a custom operator will. regards, tom lane
В списке pgsql-novice по дате отправления: