Re: generate_series for timestamptz and time zone problem

Przemysław Sztoch wrote on 01.07.2022 15:43:
> 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?
Dear Gurjeet,
I thought a bit after riding the bikes and the code repaired itself. :-)
Thanks for the clarification. Please check if patch v5 is satisfactory 
for you.
>> 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.
Have I convinced everyone that this change is right? I assume I'm right 
and the mistake will be fatal.

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