Re: generate_series for timestamptz and time zone problem

Gurjeet Singh wrote on 01.07.2022 06:35:

On Tue, Jun 21, 2022 at 7:56 AM Przemysław Sztoch <przemyslaw@sztoch.pl> wrote:

Please give me feedback on how to properly store the timezone name in the function context structure. I can't finish my work without it.

The way I see it, I don't think you need to store the tz-name in the
function context structure, like you're currently doing. I think you
can remove the additional member from the
generate_series_timestamptz_fctx struct, and refactor your code in
generate_series_timestamptz() to work without it.; you seem to  be
using the tzname member almost as a boolean flag, because the actual
value you pass to DFCall3() can be calculated without first storing
anything in the struct.

Do I understand correctly that functions that return SET are executed multiple times?
Is access to arguments available all the time?
I thought PG_GETARG_ could only be used when SRF_IS_FIRSTCALL () is true - was I right or wrong?

Can you please explain why you chose to remove the provolatile
attribute from the existing entry of date_trunc in pg_proc.dat.

I believe it was a mistake in PG code.
All timestamptz functions must be STABLE as they depend on the current: SHOW timezone.
If new functions are created that pass the zone as a parameter, they become IMMUTABLE.
FIrst date_trunc function implementaion was without time zone parameter and someone who
added second variant (with timezone as parameter) copied the definition without removing the STABLE flag.

It seems like you've picked/reused code from neighboring functions
(e.g. from timestamptz_trunc_zone()). Can you please see if you can
turn such code into a function, and  call the function, instead of
copying it.

Ok. Changed.

Also, according to the comment at the top of pg_proc.dat,
 # Once upon a time these entries were ordered by OID.  Lately it's often # been the custom to insert new entries adjacent to related older entries.

So instead of adding your entries at the bottom of the file, please
each entry closer to an existing entry that's relevant to it.

Ok. Changed.

Some regression tests has been added.

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.)
-- Note: ignore aggregate functions here, since they all point to the same
-- dummy built-in function.
SELECT p1.oid, p1.proname, p2.oid, p2.proname (...):
 oid  |         proname         | oid  |     proname
------+-------------------------+------+-----------------
 1189 | timestamptz_pl_interval | 8800 | date_add
  939 | generate_series         | 8801 | generate_series
(2 rows)