Alvaro Herrera wrote:
> Is there a better way than going to time_t and back? I am currently
> using this:
>
> db->next_worker =
> time_t_to_timestamptz(timestamptz_to_time_t(current_time) +
> autovacuum_naptime);
>
> (db->next_worker is a T
Grzegorz Jaskiewicz wrote:
>
> On Mar 15, 2007, at 5:58 AM, Tom Lane wrote:
>
> >
> >? I'm not sure what would be the most convenient realization
> >of this at the C level, but please stay away from time_t ...
>
> what's wrong with time_t ? Does postgres has some sort of "time" API,
> that ca
If you read the autovacuum_naptime into an Interval object once, why can't
you just use timestamptz_pl_interval ? You won't be using the interval
input/output repeatedly surely.
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
-Original Mes
On Mar 15, 2007, at 5:58 AM, Tom Lane wrote:
? I'm not sure what would be the most convenient realization
of this at the C level, but please stay away from time_t ...
what's wrong with time_t ? Does postgres has some sort of "time" API,
that can be used instead?
--
Grzegorz Jaskiewicz
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Is there a better way than going to time_t and back?
>
> Isn't the standard SQL-level locution
> timestamptz + numeric_value * '1 second'::interval
> ? I'm not sure what would be the most convenient realization
> of this at th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is there a better way than going to time_t and back?
Isn't the standard SQL-level locution
timestamptz + numeric_value * '1 second'::interval
? I'm not sure what would be the most convenient realization
of this at the C level, but please stay a
