From: | Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generate_series for timestamptz and time zone problem |
Date: | 2022-07-01 13:43:05 |
Message-ID: | eaa3fabe-50fc-bbe8-b096-ce62ddadab85@sztoch.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
generate_series_with_timezone_date_trunc_v4.patch | text/plain | 27.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-07-01 13:50:21 | Re: drop support for v9.3 ? |
Previous Message | Tom Lane | 2022-07-01 13:40:42 | Re: doc: Clarify what "excluded" represents for INSERT ON CONFLICT |