Re: value returned by EXTRACT, date_part - Mailing list pgsql-sql

From John Lumby
Subject Re: value returned by EXTRACT, date_part
Date
Msg-id DM6PR06MB55625C1A9319BC921F4FB4ACA3530@DM6PR06MB5562.namprd06.prod.outlook.com
Whole thread Raw
In response to Re: value returned by EXTRACT, date_part  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: value returned by EXTRACT, date_part  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
Thanks Tom

On 2020-08-28 21:39, Tom Lane wrote:
>
> 4.6.3 "Intervals" lays down basically the same sorts of rules for
> intervals: they are made of component fields and only the seconds
> field can have a fractional part.

What is not clear to me is how the "components"  (aka "subfields") of an 
interval are defined.

e.g.


SELECT EXTRACT(days FROM INTERVAL '1 year 35 days 1 minute');
  date_part
-----------
         35

ok,     it takes the interval modulo months (the next higher unit than 
the one I requested) and then rounds that down.


But

SELECT EXTRACT(days FROM INTERVAL '400 days 1 minute');
  date_part
-----------
        400

oh!    no it doesn't ...


>
> PG does offer a nonstandard EPOCH "field" in EXTRACT, which tries
> to convert the timestamp or interval as a whole to some number of
> seconds.  Possibly you could make use of that, perhaps after first
> applying date_trunc, to get what you're after.  The whole enterprise
> is pretty shaky though; for example you cannot convert months to days
> or vice versa without making fundamentally-indefensible assumptions.


Yes!        That is exactly what I am looking for.    Actually for 
simplicity I think I don't need date_trunc;

for this particular case of wanting to find the size of an interval,

it is as simple as always requesting its epoch and working in 
double-precision seconds.

Thanks!


>
>             regards, tom lane
> .



pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: value returned by EXTRACT, date_part
Next
From: Tom Lane
Date:
Subject: Re: value returned by EXTRACT, date_part