Re: generate_series for timestamptz and time zone problem

Przemysław Sztoch <przemyslaw@sztoch.pl>

From: Przemysław Sztoch <przemyslaw@sztoch.pl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2022-06-21T14:55:40Z
Lists: pgsql-hackers

Attachments


Przemysław Sztoch wrote on 14.06.2022 21:46:
> Tom Lane wrote on 14.06.2022 15:43:
>> =?UTF-8?Q?Przemys=c5=82aw_Sztoch?=<przemyslaw@sztoch.pl>  writes:
>>> Please let me know what is the convention (procedure) of adding new
>>> functions to pg_proc. Specifically how oid is allocated.
>> See
>> https://www.postgresql.org/docs/devel/system-catalog-initial-data.html#SYSTEM-CATALOG-OID-ASSIGNMENT
>> (you should probably read that whole chapter for context).
> Thx.
>
> There is another patch.
> It works, but one thing is wrongly done because I lack knowledge.
>
> Where I'm using DirectFunctionCall3 I need to pass the timezone name, 
> but I'm using cstring_to_text and I'm pretty sure there's a memory 
> leak here. But I need help to fix this.
> I don't know how best to store the timezone in the generate_series 
> context. Please, help.
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.

Additionally, I added a new variant of the date_trunc function that 
takes intervals as an argument.
It enables functionality similar to date_bin, but supports monthly, 
quarterly, annual, etc. periods.
In addition, it is resistant to the problems of different time zones and 
daylight saving time (DST).

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

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.