On 3/17/16 11:55 AM, David G. Johnston wrote: > On Thu, Mar 17, 2016 at 8:41 AM, David Steele <da...@pgmasters.net > <mailto:da...@pgmasters.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 da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
