Re: generate_series for timestamptz and time zone problem

From: Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gurjeet Singh <gurjeet(at)singh(dot)im>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generate_series for timestamptz and time zone problem
Date: 2022-07-04 11:00:03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote on 04.07.2022 00:31:
> =?UTF-8?Q?Przemys=c5=82aw_Sztoch?= <przemyslaw(at)sztoch(dot)pl> writes:
>> 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.)
> It's telling you you're violating project style. Don't make multiple
> pg_proc entries point at the same C function and then use PG_NARGS
> to disambiguate; instead point at two separate functions. The functions
> can share code at the next level down, if they want. (Just looking
> at the patch, though, I wonder if sharing code is really beneficial
> in this case. It seems quite messy, and I wouldn't be surprised
> if it hurts performance in the existing case.)
> You also need to expend some more effort on refactoring code, to
> eliminate silliness like looking up the timezone name each time
> through the SRF. That's got to be pretty awful performance-wise.
> regards, tom lane
Thx. Code is refactored. It is better, now.

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

Attachment Content-Type Size
generate_series_with_timezone_date_trunc_v5.patch text/plain 30.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-07-04 11:07:50 Re: EINTR in ftruncate()
Previous Message Etsuro Fujita 2022-07-04 10:59:45 Re: Error from the foreign RDBMS on a foreign table I have no privilege on