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(at)sztoch(dot)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)

--
Przemysław Sztoch | Mobile +48 509 99 00 66