|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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:
If new functions are created that pass the zone as a parameter, they
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.
> 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.
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
-- 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
Przemysław Sztoch | Mobile +48 509 99 00 66
|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|