Re: generate_series for timestamptz and time zone problem

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Przemysław Sztoch <przemyslaw@sztoch.pl>
Cc: Gurjeet Singh <gurjeet@singh.im>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2022-07-03T22:31:29Z
Lists: pgsql-hackers
=?UTF-8?Q?Przemys=c5=82aw_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



Commits

  1. Add functions to do timestamptz arithmetic in a non-default timezone.

  2. Refactor datetime functions' timezone lookup code to reduce duplication.

  3. Fix volatility marking of timestamptz_trunc_zone.