Tom Lane wrote on 04.07.2022 00:31:
> =?UTF-8?Q?Przemys=c5=82aw_Sztoch?= <przemyslaw(at)sztoch(dot)pl> writes:
>> I have problem with this:
>> -- Considering only built-in procs (prolang = 12), look for multiple uses
>> -- of the same internal function (ie, matching prosrc fields). It's OK to
>> -- have several entries with different pronames for the same internal
>> function,
>> -- but conflicts in the number of arguments and other critical items should
>> -- be complained of. (We don't check data types here; see next query.)
> It's telling you you're violating project style. Don't make multiple
> pg_proc entries point at the same C function and then use PG_NARGS
> to disambiguate; instead point at two separate functions. The functions
> can share code at the next level down, if they want. (Just looking
> at the patch, though, I wonder if sharing code is really beneficial
> in this case. It seems quite messy, and I wouldn't be surprised
> if it hurts performance in the existing case.)
>
> You also need to expend some more effort on refactoring code, to
> eliminate silliness like looking up the timezone name each time
> through the SRF. That's got to be pretty awful performance-wise.
>
> regards, tom lane
Thx. Code is refactored. It is better, now.
--
Przemysław Sztoch | Mobile +48 509 99 00 66