Re: Add generate_series(numeric, numeric) - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Add generate_series(numeric, numeric)
Date
Msg-id CAHGQGwFKbn2HwoH+1=DWvBjMk8nJMLe5ghkecFRh9U_Ab5Wnaw@mail.gmail.com
Whole thread Raw
In response to Re: Add generate_series(numeric, numeric)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
On Mon, Dec 15, 2014 at 12:25 PM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Fujii" == Fujii Masao <masao.fujii@gmail.com> writes:
>
>  Fujii> Pushed.
>
> Bug found:
>
> regression=# select count(*) from generate_series(1::numeric,10) v, generate_series(1,v) w;
>  count
> -------
>  99990
> (1 row)
>
> regression=# select count(*) from generate_series(1::numeric,10) v, generate_series(1,v+0) w;
>  count
> -------
>     55
> (1 row)
>
> The error is in the use of PG_GETARG_NUMERIC and init_var_from_num
> when setting up the multi-call state; init_var_from_num points at the
> original num's digits rather than copying them, but start_num and
> stop_num have just been (potentially) detoasted in the per-call
> context, in which case the storage will have been freed by the next
> call.
>
> Obviously this could also be fixed by not detoasting the input until
> after switching to the multi-call context, but it looks to me like
> that would be unnecessarily complex.
>
> Suggested patch attached.

Pushed. Thanks!

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: TABLESAMPLE patch
Next
From: Fujii Masao
Date:
Subject: Re: Add generate_series(numeric, numeric)