From: | Ali Akbar <the(dot)apaan(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Платон Малюгин <malugin(dot)p(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add generate_series(numeric, numeric) |
Date: | 2014-10-05 08:21:47 |
Message-ID: | CACQjQLr5MsPprcxVHRp1OzOU5PZ8Gv2WgYWQ9YyDJ+_cv-E=zg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
Oops, it seems that I have been too hasty here. With a fresh mind I looked
at my own patch again and found two bugs:
>
>> - Incorrect calculation of each step's value, making stuff crash, it is
>> necessary to switch to the context of the function to perform operations on
>> a temporary variable first
>>
>
- i think you can use the fctx->current variable without temporary variable
(there's comment in the add_var function: Full version of add functionality
on variable level (handling signs). result might point to one of the
operands too without danger.). But you _must_ switch the context first
because add_var will allocate new array for the data and freeing the old
one.
- numeric can be NaN. We must reject it as first, finish and last parameter.
- numeric datatype is large, but there are limitations. According to doc,
the limit is: up to 131072 digits before the decimal point; up to 16383
digits after the decimal point. How can we check if the next step
overflows? As a comparison, in int.c, generate_series_step_int4 checks if
its overflows, and stop the next call by setting step to 0. Should we do
that?
~ will try to fix the patch later
--
Ali Akbar
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-10-05 10:30:52 | RLS with check option - surprised design |
Previous Message | Gregory Smith | 2014-10-05 07:57:46 | Re: proposal for 9.5: monitoring lock time for slow queries |