Re: Add generate_series(numeric, numeric)

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Ali Akbar <the(dot)apaan(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, Платон Малюгин <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-12-15 03:25:26
Message-ID: 87mw6ppraf.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Fujii" == Fujii Masao <masao(dot)fujii(at)gmail(dot)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.

(Is it also worth putting an explicit warning about this kind of thing
in the SRF docs?)

--
Andrew (irc:RhodiumToad)

Attachment Content-Type Size
ngs.patch text/x-patch 2.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-12-15 03:26:25 Re: alter user/role CURRENT_USER
Previous Message Michael Paquier 2014-12-15 03:19:15 Re: [REVIEW] Re: Fix xpath() to return namespace definitions