Skip site navigation (1) Skip section navigation (2)

Re: plpgsql: numeric assignment to an integer variable errors out

From: "Nikhil Sontakke" <nikhil(dot)sontakke(at)enterprisedb(dot)com>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql: numeric assignment to an integer variable errors out
Date: 2008-12-30 07:04:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

> >
> >> 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.
> +1
> 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.


Attachment: plpgsql_numeric_bug_v2.0.patch
Description: text/x-diff (3.1 KB)

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2008-12-30 08:42:06
Subject: version() output vs. 32/64 bits
Previous:From: Bryce CuttDate: 2008-12-30 05:29:06
Subject: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group