Re: plpgsql: numeric assignment to an integer variable errors out
От | Nikhil Sontakke |
---|---|
Тема | Re: plpgsql: numeric assignment to an integer variable errors out |
Дата | |
Msg-id | a301bfd90812292304w39479604sf3539433b8b50ed1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql: numeric assignment to an integer variable errors out ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: plpgsql: numeric assignment to an integer
variable errors out
|
Список | pgsql-hackers |
Hi,
Agreed, it can slow things down a bit especially since we are only interested in the COERCION_PATH_FUNC case. What we need is a much simpler pathway function which searches in the SysCache and returns back with the valid/invalid castfunc immediately.
PFA, version 2.0 of this patch with these changes in place. I could have added a generic function in parse_coerce.c, but thought the use case was restricted to plpgsql and hence I have kept it within pl_exec.c for now.
Regards,
Nikhils
--
http://www.enterprisedb.com
+1>
>> The following plpgsql function errors out with cvs head:
>>
>> CREATE function test_assign() returns void
>> AS
>> $$ declare x int;
>> BEGIN
>> x := 9E3/2;
>> END
>> $$ LANGUAGE 'plpgsql';
>>
>> postgres=# select test_assign();
>> ERROR: invalid input syntax for integer: "4500.0000000000000000"
>> CONTEXT: PL/pgSQL function "test_assign" line 3 at assignment
>>
>> We do have an existing cast from numeric to type integer. But here
>> basically we convert the value to string in exec_cast_value before calling
>> int4in. And then use of strtol in pg_atoi leads to this complaint. Guess
>> converting the value to string is not always a good strategy.
>
> PFA, patch which uses find_coercion_pathway to find a direct
> COERCION_PATH_FUNC function and uses that if it is available. Or is there a
> better approach? Seems to handle the above issue with this patch.
I thing, so some values should by cached, current patch could by slow.
Agreed, it can slow things down a bit especially since we are only interested in the COERCION_PATH_FUNC case. What we need is a much simpler pathway function which searches in the SysCache and returns back with the valid/invalid castfunc immediately.
PFA, version 2.0 of this patch with these changes in place. I could have added a generic function in parse_coerce.c, but thought the use case was restricted to plpgsql and hence I have kept it within pl_exec.c for now.
Regards,
Nikhils
http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: