From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Procedure for feature requests? |
Date: | 2009-10-28 10:41:30 |
Message-ID: | 20091028104130.GP5407@samason.me.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | JC Praud | 2009-10-28 10:53:35 | Re: auto truncate/vacuum full |
Previous Message | Vasiliy G Tolstov | 2009-10-28 10:10:02 | log slow queries and hints |