On 23.05.2011 17:33, Tom Lane wrote:
Not sure I trust this fix to catch all cases --- seems like the addition
could still overflow. It'd probably be better if we made this code look
like the overflow test in scanint8:
int64 newtmp = tmp * 10 + (*ptr++ - '0');
if ((newtmp / 10) != tmp) /* overflow? */
It might be good to replace the loop altogether with strtoul() here, for
readability purposes if nothing else.
I also note that there's no overflow check in plain "%s" case which does
"++arg". It seems impossible to cause that overflow, because a function
can't have more than 100 arguments, but it doesn't make me feel very
comfortable.
It's actually possible to pass more than 100 arguments using the
VARIADIC keyword, along the lines of:
CREATE FUNCTION my_concat(variadic text[]) RETURNS text LANGUAGE SQL AS
$$ SELECT array_to_string($1,''); $$;
SELECT my_concat(VARIADIC (SELECT array_agg(a::text) FROM
generate_series(1,1000) a));
However, built-in concat and text_format functions don't seem to behave
that way:
postgres=# SELECT my_concat(VARIADIC (SELECT array_agg(a::text) FROM
generate_series(1,10) a));
my_concat
-------------
12345678910
(1 row)
postgres=# SELECT concat(VARIADIC (SELECT array_agg(a::text) FROM
generate_series(1,10) a));
concat
------------------------
{1,2,3,4,5,6,7,8,9,10}
(1 row)
I'm not sure what's going on here, something funny with the fact that
those take an 'any' argument, I guess.
It's a stretch that we'd ever support two billion arguments in any form,
but an explicit check for "arg < 0" would make me feel better.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
