> >> 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
> >> 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
> > 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.
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2008-12-30 08:42:06|
|Subject: version() output vs. 32/64 bits|
|Previous:||From: Bryce Cutt||Date: 2008-12-30 05:29:06|
|Subject: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets|