On 01/22/2016 04:28 AM, Tom Lane wrote:
> Vik Fearing writes:
>> I looked around for other places where this code should be used and
>> didn't find any. I am marking this patch Ready for Committer.
>
> I pushed this with some adjustments, mainly to make sure that the
> erroneous-units errors exa
On 1/21/16, Tom Lane wrote:
> Vik Fearing writes:
>> I looked around for other places where this code should be used and
>> didn't find any. I am marking this patch Ready for Committer.
>
> I pushed this with some adjustments, mainly to make sure that the
> erroneous-units errors exactly match t
Vik Fearing writes:
> I looked around for other places where this code should be used and
> didn't find any. I am marking this patch Ready for Committer.
I pushed this with some adjustments, mainly to make sure that the
erroneous-units errors exactly match those that would be thrown in
the main
On 01/05/2016 09:07 AM, Vitaly Burovoy wrote:
> On 1/4/16, Alvaro Herrera wrote:
>> It seems we got majority approval on the design of this patch, and no
>> disagreement; the last submitted version appears to implement that.
>> There's no documentation change in the patch though. I'm marking it a
On 1/4/16, Alvaro Herrera wrote:
> Vitaly Burovoy wrote:
>
>> Majority of the votes for NULL for "other things" except epoch.
>> Nobody answers about differences between monotonic and oscillating
>> values.
>>
>> I suppose behavior of monotonic values (julian, century, decade,
>> isoyear, millenni
Vitaly Burovoy wrote:
> Majority of the votes for NULL for "other things" except epoch.
> Nobody answers about differences between monotonic and oscillating values.
>
> I suppose behavior of monotonic values (julian, century, decade,
> isoyear, millennium and year) should be the same as for epoch
On 17.11.2015 09:09, Vitaly Burovoy wrote:
I suppose behavior of monotonic values (julian, century, decade,
isoyear, millennium and year) should be the same as for epoch (which
obviously also monotonic value).
Proposed patch has that behavior: +/-infinity for epoch, julian,
century, decade, isoy
Jim Nasby writes:
> On 11/17/15 2:09 AM, Vitaly Burovoy wrote:
>> Proposed patch has that behavior: ±infinity for epoch, julian,
>> century, decade, isoyear, millennium and year; NULL for other fields.
> What's the logic behind NULL here? Infinity is infinity, whether it's
> minutes or years.
On Tue, Nov 17, 2015 at 10:57 AM, Tom Lane wrote:
> Vitaly Burovoy writes:
>> I suppose behavior of monotonic values (julian, century, decade,
>> isoyear, millennium and year) should be the same as for epoch (which
>> obviously also monotonic value).
>> Proposed patch has that behavior: +/-infini
Vitaly Burovoy writes:
> I suppose behavior of monotonic values (julian, century, decade,
> isoyear, millennium and year) should be the same as for epoch (which
> obviously also monotonic value).
> Proposed patch has that behavior: +/-infinity for epoch, julian,
> century, decade, isoyear, millenn
On 11/17/15 2:09 AM, Vitaly Burovoy wrote:
I suppose behavior of monotonic values (julian, century, decade,
isoyear, millennium and year) should be the same as for epoch (which
obviously also monotonic value).
Proposed patch has that behavior: ±infinity for epoch, julian,
century, decade, isoyear
On 11/9/15, Robert Haas wrote:
> On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy
> wrote:
>> I'd like to raise a topic about extracting fields from infinite
>> timestamps, so much more that it is mentioned in the TODO list:
>> "Determine how to represent date/time field extraction on infinite
>> t
On 09.11.2015 17:41, Tom Lane wrote:
Kevin Grittner writes:
On Monday, November 9, 2015 9:37 AM, Robert Haas wrote:
That doesn't seem like enough consensus to commit this patch, which
would change everything to +/-infinity. That particular choice
wouldn't bother me much, but it sounds like
> On Mon, Nov 9, 2015 at 8:22 AM, Kevin Grittner wrote:
>> My first choice for other things would be NaN, but throwing an
>> error instead would be OK.
On Monday, November 9, 2015 10:41 AM, Tom Lane wrote:
> What about returning NULL for the ill-defined cases? That seems
> to comport with SQL'
I was unaware that we had +- infinity for numeric.
select pg_typeof(extract(epoch from current_date));
pg_typeof
--
double precision
Given that null is a "special value that is used to indicate the absence of
any data value" and that attributes like month or day-of-week will ha
Kevin Grittner writes:
> On Monday, November 9, 2015 9:37 AM, Robert Haas
> wrote:
>> That doesn't seem like enough consensus to commit this patch, which
>> would change everything to +/-infinity. That particular choice
>> wouldn't bother me much, but it sounds like other people aren't sold.
>>
On Monday, November 9, 2015 9:37 AM, Robert Haas wrote:
> On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy
> wrote:
>> I'd like to raise a topic about extracting fields from infinite
>> timestamps, so much more that it is mentioned in the TODO list:
>> "Determine how to represent date/time field
On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy wrote:
> I'd like to raise a topic about extracting fields from infinite
> timestamps, so much more that it is mentioned in the TODO list:
> "Determine how to represent date/time field extraction on infinite
> timestamps".
>
> Currently extracting any
Hackers!
I'd like to raise a topic about extracting fields from infinite
timestamps, so much more that it is mentioned in the TODO list:
"Determine how to represent date/time field extraction on infinite
timestamps".
Currently extracting any field from 'infinity'::TIMESTAMP[TZ] gives
result "0" a
19 matches
Mail list logo