David Steele <da...@pgmasters.net> writes:
> On 12/15/20 9:03 AM, Peter Eisentraut wrote:
>> Here is a new patch for this. This now follows the implementation that
>> Tom has suggested: Leave date_part() alone, add a new set of extract()
>> functions, and map the SQL EXTRACT construct to those. I have basically
>> just copied over the implementations from my previous patch and placed
>> them next to the existing date_part() implementations. So all the
>> behavior is still the same as in the previous patches.
>>
>> One thing I still need to look into is how to not lose all the test
>> coverage for date_part(). But that should be fairly mechanical, so I'm
>> leaving it off in this version.
> Tom, what do you think of the updated patch?
Oh, I didn't think I was on the hook to review this ;-)
Anyway, taking a quick look at the v4 patch, the only complaint
I have is that it seems a bit bulky and brute-force to duplicate
so much code. Is it feasible to share most of the implementation
between old and new functions, returning (say) an int64 that can
then be converted to either numeric or float8 by a wrapper? That
would also reduce the pressure to duplicate all the test cases.
(I don't intend this complaint as a deal-breaker; Peter may well
have considered this alternative already and rejected it for good
reasons.)
regards, tom lane
