Re: Procedure for feature requests? - Mailing list pgsql-general

From Sam Mason
Subject Re: Procedure for feature requests?
Date
Msg-id 20091028104130.GP5407@samason.me.uk
Whole thread Raw
In response to Re: Procedure for feature requests?  (Tim Landscheidt <tim@tim-landscheidt.de>)
Responses Re: Procedure for feature requests?
List pgsql-general
On Tue, Oct 27, 2009 at 06:53:55PM +0000, Tim Landscheidt wrote:
> You would have to adjust the result of "(EXTRACT('epoch'
> FROM B) - EXTRACT('epoch' FROM A)) / EXTRACT('epoch' FROM
> C)" by a factor of 31/30 (30/28? 28/30?) and then chop off
> timestamps after B with a "WHERE" clause.

I'm not sure where you're going with this.  The original idea was
generate_series for intervals wasn't it?  When you start moving from
intervals to specific periods of time (i.e. 1st Jan 1970) then you've
lost the reason for working with intervals and you may as well just be
working with dates or timestamps.  The purpose of intervals, as far as
I can tell, is so that you can use things like '1 month' and have it do
the "right" thing in our Gregorian calender.

>   JFTR: Hours can of course also be 3601 (or theoretically
> 3599) seconds long, but not in PostgreSQL :-).

Depending on the standard you use, yes.  BTW, I believe up to two leap
seconds are allowed forward in UTC.  I believe there are also plans to
drop leap seconds and let time slowly drift out of alignment.  I think
the idea is that when it starts to matter to people, in a thousand years
or so, we'll be an interplanetary species anyway and tying time to earth
this way is thought to be silly.  It also unnecessarily complicates
things that don't really care and not be good enough for things that do
care.

--
  Sam  http://samason.me.uk/

pgsql-general by date:

Previous
From: Vasiliy G Tolstov
Date:
Subject: log slow queries and hints
Next
From: JC Praud
Date:
Subject: Re: auto truncate/vacuum full