Table:
Column | Type | Modifiers
-------------------+-----------------------+---------------------------------------------------------------------
imported_date | integer | not null default 0
PG v7.2.1 (nice and clean):
select imported_date, "timestamptz"(imported_date) from server_accounts limit 1;
imported_date | timestamptz
---------------+------------------------
1037498593 | 2002-11-16 18:03:13-08
(1 row)
PG v7.3 (nasty and dirty):
select imported_date, "timestamptz"(imported_date) from server_accounts limit 1;
ERROR: Bad timestamp external representation '1027966107'
select imported_date, "timestamptz"( cast(imported_date as timestamp) ) from
server_accounts limit 1;
ERROR: Cannot cast type integer to timestamp without time zone
select imported_date, "timestamptz"( cast(imported_date as timestamptz) ) from
server_accounts limit 1;
ERROR: Cannot cast type integer to timestamp with time zone
select imported_date, ('Jan 1 1970'::DATE + (imported_date || '
seconds')::INTERVAL)::timestamp from server_accounts limit 1
imported_date | timestamp
---------------+---------------------
1027966107 | 2002-07-29 18:08:27
The last query works, but you must admit it is pretty nasty. Yes, I could create a
from_epoch() function that takes care of this, but should this really be nessecary?
Is there a better way to go about this in v7.3 without changing the column type?
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
