Pushed v7 after making a bunch of cosmetic changes. One gripe
I had was that rearranging the logic in timestamptz_pl_interval[_internal]
made it nearly impossible to see what functional changes you'd made
there, while not really buying anything in return. I undid that to
make the diff readable.
On 31/01/2023 08:50, Gurjeet Singh wrote:
On Mon, Jan 30, 2023 at 4:07 PM Tom Lane wrote:
Gurjeet Singh writes:
[ generate_series_with_timezone.v6.patch ]
The cfbot isn't terribly happy with this. It looks like UBSan
is detecting some undefined behavior. Possibly an uninitialized
Gurjeet Singh writes:
> Please see attached the patch to that ensures we don't accidentally
> access more parameters than that are passed to a SQL callable
> function.
I'm unexcited by that. It'd add a pretty substantial amount
of code to catch an error that hardly anyone ever makes.
On Mon, Jan 30, 2023 at 11:50 PM Gurjeet Singh wrote:
> It was the classical case of out-of-bounds access.
> This mistake would've been caught early if there were assertions
> preventing access beyond the number of arguments passed to the
> function. I'll send the assert_enough_args.patch, that
On Mon, Jan 30, 2023 at 4:07 PM Tom Lane wrote:
> Gurjeet Singh writes:
> > [ generate_series_with_timezone.v6.patch ]
>
> The cfbot isn't terribly happy with this. It looks like UBSan
> is detecting some undefined behavior. Possibly an uninitialized
> variable?
It was the classical case of
Gurjeet Singh writes:
> [ generate_series_with_timezone.v6.patch ]
The cfbot isn't terribly happy with this. It looks like UBSan
is detecting some undefined behavior. Possibly an uninitialized
variable?
regards, tom lane
Gurjeet Singh wrote on 30.01.2023 08:18:
On Sat, Nov 12, 2022 at 10:44 AM Tom Lane wrote:
However, what it shouldn't be is part of this patch. It's worth
pushing it separately to have a record of that decision. I've
now done that, so you'll need to rebase to remove that delta.
I looked
Gurjeet Singh writes:
> On Sat, Nov 12, 2022 at 10:44 AM Tom Lane wrote:
>> I looked over the v5 patch very briefly, and have two main
>> complaints:
>> ...
> Please see attached v6 of the patch.
Thanks for updating that!
> I'm not sure of the convention around authorship. But since this was
On Sat, Nov 12, 2022 at 10:44 AM Tom Lane wrote:
> However, what it shouldn't be is part of this patch. It's worth
> pushing it separately to have a record of that decision. I've
> now done that, so you'll need to rebase to remove that delta.
>
> I looked over the v5 patch very briefly, and
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes:
> Gurjeet Singh wrote on 01.07.2022 06:35:
>> 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
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 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
Tom Lane wrote on 04.07.2022 00:31:
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= 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
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= 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
Gurjeet Singh wrote on 01.07.2022 06:35:
On Tue, Jun 21, 2022 at 7:56 AM Przemysław Sztoch 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
On Tue, Jun 21, 2022 at 7:56 AM Przemysław Sztoch wrote:
> There is another patch.
> It works, but one thing is wrongly done because I lack knowledge.
Thank you for continuing to work on it despite this being your first
time contributing, and despite the difficulties. I'll try to help as
much as
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?= writes:
Please let me know what is the convention (procedure) of adding new
functions to pg_proc. Specifically how oid is allocated.
See
Tom Lane wrote on 14.06.2022 15:43:
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes:
Please let me know what is the convention (procedure) of adding new
functions to pg_proc. Specifically how oid is allocated.
See
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= 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
Dear colleagues,
Please let me know what is the convention (procedure) of adding new
functions to pg_proc. Specifically how oid is allocated.
This will allow me to continue working on the patch.
I have to extend the timestamptz_pl_interval function, which is in fact
an addition operator. But
Tom Lane wrote on 31.05.2022 22:54:
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes:
|generate_series| ( /|start|/ |timestamp with time zone|, /|stop|/
|timestamp with time zone|, /|step|/ |interval| )
produces results depending on the timezone value set:
That's intentional. If you don't want
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes:
> |generate_series| ( /|start|/ |timestamp with time zone|, /|stop|/
> |timestamp with time zone|, /|step|/ |interval| )
> produces results depending on the timezone value set:
That's intentional. If you don't want it, maybe you should be using
|generate_series| ( /|start|/ |timestamp with time zone|, /|stop|/
|timestamp with time zone|, /|step|/ |interval| )
produces results depending on the timezone value set:
SET timezone = 'UTC';
SELECT ts, ts AT TIME ZONE 'UTC'
FROM generate_series('2022-03-26 00:00:00+01'::timestamptz,
22 matches
Mail list logo
