X-Original-To: pgsql-sql@postgresql.org
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
	by postgresql.org (Postfix) with ESMTP id EAB6F4762E9
	for <pgsql-sql@postgresql.org>; Tue, 11 Mar 2003 23:42:37 -0500 (EST)
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
	id DAE69D612; Tue, 11 Mar 2003 20:42:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by megazone.bigpanda.com (Postfix) with ESMTP
	id C28245C04; Tue, 11 Mar 2003 20:42:42 -0800 (PST)
Date: Tue, 11 Mar 2003 20:42:42 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: patrick <patrick+pgsql@boxsoft.com>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: converting time_t to timestamp?
In-Reply-To: <20030311185704.D24959@3eye.boxsoft.com>
Message-ID: <20030311203552.S48276-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Archive-Number: 200303/274
X-Sequence-Number: 12314


On Tue, 11 Mar 2003, patrick wrote:

> I'm reposting this question since I received zero replies from my
> original post (maybe the original subject line was misleading).

> I've just^W upgraded from PostgreSQL 7.1.2 to 7.3.2.
>
> In 7.1.2 I was able to use the output of time(2) (and the like) to
> insert into a field of timestamp type.
>
> First thing i noticed with the upgrade was that the following broke:

The old syntax somewhat conflicted with the full type specifier when we
added the precision stuff.  Unfortunately, the change caught alot of
people. :(

>
>   in 7.1.2
>   => select timestamp ( 1046923200 );
>       timestamp
>   ------------------------
>    2003-03-05 20:00:00-08
>   (1 row)
>
>   in 7.3.2
>   => select timestamp ( 1046923200 );
>   ERROR:  TIMESTAMP(1046923200) precision must be between 0 and 6
>
>
> Can anyone point me to a work-around?
>
> I notice that I can use abstime( 1046923200 ) to get the desired
> result.  But is this the optimal way to do this?

 'epoch'::timestamp + (<integer> * '1 second'::interval);

seems more explicit to me (in its intention), but probably isn't as
efficient as the int4->abstime->timestamp path.