Tom Lane wrote on 04.07.2022 00:31:Przemysław Sztoch <przemyslaw@sztoch.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
