Re: generate_series for timestamptz and time zone problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>
Cc: Gurjeet Singh <gurjeet(at)singh(dot)im>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generate_series for timestamptz and time zone problem
Date: 2022-07-03 22:31:29
Message-ID: 1396355.1656887489@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-07-03 22:33:37 Re: AIX support - alignment issues
Previous Message Peter Smith 2022-07-03 22:29:03 Re: Handle infinite recursion in logical replication setup