On Wed, Jan 14, 2015 at 11:04 AM, Ali Akbar wrote:
>
> 2014-12-18 19:35 GMT+07:00 Fujii Masao :
>>
>> On Mon, Dec 15, 2014 at 2:38 PM, Andrew Gierth
>> wrote:
>> > I was thinking something like this, added just after that para:
>> >
>> >
>> >
>> > While the actual arguments to th
2014-12-18 19:35 GMT+07:00 Fujii Masao :
> On Mon, Dec 15, 2014 at 2:38 PM, Andrew Gierth
> wrote:
> > I was thinking something like this, added just after that para:
> >
> >
> >
> > While the actual arguments to the function remain unchanged between
> > calls, if you detoa
On Mon, Dec 15, 2014 at 2:38 PM, Andrew Gierth
wrote:
>> "Ali" == Ali Akbar writes:
>
> Ali> I think yes, it will be good. The alternative is restructuring
> Ali> this paragraph in the SRF docs:
>
> >> The memory context that is current when the SRF is called is a
> >> transient context
On Mon, Dec 15, 2014 at 12:25 PM, Andrew Gierth
wrote:
>> "Fujii" == Fujii Masao writes:
>
> Fujii> Pushed.
>
> Bug found:
>
> regression=# select count(*) from generate_series(1::numeric,10) v,
> generate_series(1,v) w;
> count
> ---
> 0
> (1 row)
>
> regression=# select count(*)
> "Ali" == Ali Akbar writes:
Ali> I think yes, it will be good. The alternative is restructuring
Ali> this paragraph in the SRF docs:
>> The memory context that is current when the SRF is called is a
>> transient context that will be cleared between calls. This means
>> that you do not
2014-12-15 10:25 GMT+07:00 Andrew Gierth :
>
> > "Fujii" == Fujii Masao writes:
>
> Fujii> Pushed.
>
> Bug found:
>
> regression=# select count(*) from generate_series(1::numeric,10) v,
> generate_series(1,v) w;
> count
> ---
> 0
> (1 row)
>
> regression=# select count(*) from gener
> "Fujii" == Fujii Masao writes:
Fujii> Pushed.
Bug found:
regression=# select count(*) from generate_series(1::numeric,10) v,
generate_series(1,v) w;
count
---
0
(1 row)
regression=# select count(*) from generate_series(1::numeric,10) v,
generate_series(1,v+0) w;
count
---
On Fri, Nov 7, 2014 at 3:19 PM, Fujii Masao wrote:
> On Tue, Oct 14, 2014 at 3:22 PM, Michael Paquier
> wrote:
>>
>>
>> On Tue, Oct 7, 2014 at 8:38 AM, Ali Akbar wrote:
>>>
>>> 2014-10-06 22:51 GMT+07:00 Marti Raudsepp :
>>>
>>>
> the one that tests values just before numeric overflow
On Tue, Oct 14, 2014 at 3:22 PM, Michael Paquier
wrote:
>
>
> On Tue, Oct 7, 2014 at 8:38 AM, Ali Akbar wrote:
>>
>> 2014-10-06 22:51 GMT+07:00 Marti Raudsepp :
>>
>>
>>>
>>> > the one that tests values just before numeric overflow
>>>
>>> Actually I don't know if that's too useful. I think you s
On Tue, Oct 7, 2014 at 8:38 AM, Ali Akbar wrote:
> 2014-10-06 22:51 GMT+07:00 Marti Raudsepp :
>
>
>
>> > the one that tests values just before numeric overflow
>>
>> Actually I don't know if that's too useful. I think you should add a
>> test case that causes an error to be thrown.
>>
>
> Actual
2014-10-06 22:51 GMT+07:00 Marti Raudsepp :
> That's fine I think, it's just for tracking who made the changes in
> the CommitFest app. What actually matters is what you write in the
> "Author" field, which could contain all 3 names separated by commas.
>
Ok. Added to commitfest:
https://commitfe
On Tue, Oct 7, 2014 at 12:51 AM, Marti Raudsepp wrote:
> On Mon, Oct 6, 2014 at 6:12 PM, Ali Akbar wrote:
> > User apaan is me. When i added to the commitfest, the patch is listed
> there
> > by me (apaan).
> That's fine I think, it's just for tracking who made the changes in
> the CommitFest ap
On Mon, Oct 6, 2014 at 6:12 PM, Ali Akbar wrote:
> User apaan is me. When i added to the commitfest, the patch is listed there
> by me (apaan).
That's fine I think, it's just for tracking who made the changes in
the CommitFest app. What actually matters is what you write in the
"Author" field, wh
> + select * from generate_series(0.1::numeric, 10.0::numeric, 0.1::numeric);
> + generate_series
> + -
> + 0.1
> ...
> + 10.0
> + (100 rows)
>
> Unless there is a good reason, can you please keep individual test
> output fewer than 100 lines? I think the 4
I'm a bit confused about who I should be replying to, but since you
were the last one with a patch...
On Mon, Oct 6, 2014 at 11:44 AM, Ali Akbar wrote:
> Thanks for the review. Attached the formatted patch according to your
> suggestion.
+ select * from generate_series(0.1::numeric, 10.0::numeri
Thanks for the review. Attached the formatted patch according to your
suggestion.
- 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 ste
On Sun, Oct 5, 2014 at 7:39 PM, Ali Akbar wrote:
>
> 2014-10-05 15:21 GMT+07:00 Ali Akbar :
>
>> - 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
Also, Платон Малюгин, can you add this patch to postgresql commitfest (
http://commitfest.postgresql.org)?
--
Ali Akbar
2014-10-05 15:21 GMT+07:00 Ali Akbar :
> 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 functio
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 variabl
On Tue, Sep 30, 2014 at 10:00 AM, Michael Paquier wrote:
>
>
> On Mon, Sep 29, 2014 at 4:19 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>>
>> Michael
>> Btw, while looking at your patch, I actually hacked it a bit and finished
>> with the attached:
>> - changed process to use Nume
On Mon, Sep 29, 2014 at 4:19 PM, Michael Paquier
wrote:
>
> Michael
> Btw, while looking at your patch, I actually hacked it a bit and finished
> with the attached:
> - changed process to use NumericVar instead of Numeric
> - addition of custom step values with a function
> generate_series(numeri
Hi,
Nice patch! And welcome here.
On Mon, Sep 29, 2014 at 12:42 PM, Платон Малюгин
wrote:
> Could you help to find mistakes?
>
This implementation is rather broken, particularly when thinking that this
code could be used with a negative step... I also see no point in saving
explicitly the step
Hi,
I am newbie in postgresql development, so i took easy item in Todo list "
Add generate_series(numeric, numeric)". First, i changed function with
analogue funcionality (generate_series_timestamp) and added new object in
pg_proc (object id is 6000). My changes successfully was compiled.
I have
24 matches
Mail list logo
