Re: Add generate_series(numeric, numeric)

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

In response to

Responses

Browse pgsql-hackers by date

  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