Re: Add generate_series(date,date) and generate_series(date,date,integer)

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add generate_series(date,date) and generate_series(date,date,integer)
Date: 2016-01-25 09:55:48
Message-ID: 56A5F124.1080107@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/25/2016 07:22 AM, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>>> One thing I discovered in doing this patch is that if you do a timestamp
>>> generate_series involving infinity....it tries to do it. I didn't wait to
>>> see if it finished.
>
>> Well, I would think that this is a bug that we had better address and
>> backpatch. It does not make much sense to use infinity for timestamps,
>> but letting it run infinitely is not good either.
>
> Meh. Where would you cut it off? AD 10000000000? A few zeroes either
> way doesn't really make much difference.

Why cut off? Why not to check if any of the input values is an infinity
and simply error out in that case?

>
> If it didn't respond to SIGINT, that would be an issue, but
> otherwise this doesn't seem much more exciting than any other way to
> create a query that will run longer than you want to wait.

I disagree. Sure, it's possible to construct queries that take forever,
but that's difficult (or impossible) to detect at query start. I don't
think that means we should not guard against cases that are provably
infinite and can't possibly work.

Imagine for example a script that in some rare cases passes happens to
pass infinity into generate_series() - in that case I'd much rather
error out than wait till the end of the universe.

So +1 from me to checking for infinity.

regard

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2016-01-25 10:07:17 Re: easy way of copying regex_t
Previous Message Tomas Vondra 2016-01-25 09:50:04 Re: silent data loss with ext4 / all current versions