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

On 3/17/16 11:55 AM, David G. Johnston wrote:

> On Thu, Mar 17, 2016 at 8:41 AM, David Steele <david(at)pgmasters(dot)net
> <mailto:david(at)pgmasters(dot)net>>wrote:
>
>> Not sure I agree. My point was that even if developers were pretty
>> careful with their casting (or are using two actual dates) then there's
>> still possibility for breakage.
>
> With the first argument casted to date it doesn't matter whether you
> cast the second argument as the pseudo-type anyelement will take its
> value from the first argument and force the second to date.

Ah, I see.

> The main problem is that the system tries to cast unknown to integer
> based upon finding gs(date, date, integer) and fails without ever
> considering that gs(ts, ts, interval) would succeed.

I'm tempted to say, "why don't we just fix that?" but I'm sure any
changes in that area would introduce a variety of new and interesting
behaviors.

> ​So let the user decide whether to trade-off learning a new function
> name but getting dates instead of timestamps or going through the hassle
> of casting.​
>
> For me, it would have been a nice bonus if the generate_series() could
> be used directly but I feel that the desired functionality is desirable
> and the name itself is of only minor consideration.
>
> I can see that newbies might ponder why two functions exist but they
> should understand "backward compatibility".
>
> I suspect that most people will simply think: "use generate_series for
> numbers and use generate_dates for, well, dates". The ones left out in
> the cold are those wondering why they use "generate_series" for
> timestamp series with a finer precision than date. I'd be willing to
> offer a "generate_timestamps" to placate them. And might as well toss
> in "generate_numbers" for completeness - though now I likely doom the
> proposal...so I'll stick with just add generate_dates so the behavior is
> possible without superfluous casting or the need to write a custom
> function. Dates are too common a unit of measure to leave working with
> them this cumbersome.

I'm not finding this argument persuasive.

--
-David
david(at)pgmasters(dot)net