Re: Frustration with date/times/epoch in v7.3.
От | Stephan Szabo |
---|---|
Тема | Re: Frustration with date/times/epoch in v7.3. |
Дата | |
Msg-id | 20021212134307.I11714-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Frustration with date/times/epoch in v7.3. (Mike Benoit <mikeb@netnation.com>) |
Список | pgsql-general |
On 12 Dec 2002, Mike Benoit wrote: > Thanks Peter, abstime() seems to do the trick. However this paragraph > from the docs worries me: > > "The types abstime and reltime are lower precision types which are used > internally. You are discouraged from using any of these types in new > applications and are encouraged to move any old ones over when > appropriate. Any or all of these internal types might disappear in a > future release." > > So does this mean that the abstime() functions may dissappear in the > future? I'd rather not have to go through and change all my queries yet > again, is there a function that has a better chance of being around in > the near future that I could use instead? Actually, you were already using the existance of abstime in 7.2. The base issue that I believe caused the change is that int4->abstime used to be able to be used as an implicit cast and then the abstime could be used as an argument to timestamp(abstime) but now the cast is only allowed if used explicitly. You're probably best off wrapping it in a function "timestamp"(int) for now (probably just 'select "timestamp"($1::abstime);') as that way you're somewhat isolated from changes as long as there's a way to do the conversion (and it's possible that timestamp(int) will do what you want in the future again, since I'm not sure this was an intended consequence).
В списке pgsql-general по дате отправления: