From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, pablopumarino(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14294: Problem in generate series between dates |
Date: | 2016-08-31 22:07:50 |
Message-ID: | 878tvc4nk4.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The lack of generate_series(date,date,integer) is sometimes
>> annoying, even though it can be worked around using the
>> timestamp-without-timezone variant of generate_series.
Tom> Or you can do it with "base_date + generate_series(integer...)".
Tom> I think we looked at this when the timestamp generate_series
Tom> functions were put in, and were worried about overloading the name
Tom> so far that common use-cases would get ambiguous-function
Tom> failures. If that can be shown not to happen, though, it'd be
Tom> worth adding such a function IMO.
I don't see why there would be ambiguity. date_part already has
overloads for every date/time type without causing any issues (but
date_trunc does not, which is another source of subtle timezone bugs).
Some experimentation with creating
pg_catalog.generate_series(date,date,integer) and trying the usual
use-cases doesn't seem to turn up any issues. Looking at the list of
implicit casts also doesn't suggest that there would be any problems.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2016-08-31 23:05:04 | Re: BUG #14294: Problem in generate series between dates |
Previous Message | Tom Lane | 2016-08-31 21:33:24 | Re: BUG #14294: Problem in generate series between dates |