Re: Numerics of diffrent scales Raises Type Mismatch Error in a Set Returning Function

On Sun, 2010-03-07 at 15:08 -0800, Josh Berkus wrote:
> Per pgsql-bugs, it's an expected compatibility issue due to unifying the
> SQL and PLPGSQL parsers. That is, the fact that plpgsql used to let you
> do this was regarded as a bug, and was not consistent with the SQL
> command line.
>
> Worth noting in the release notes as part of a general class of
> backwards-compatibility issues.
>
> --Josh Berkus
>

Note that this behavior change affects seems to affect other types who's
size is different such as character varying.

I'm probably not understanding, but I'm not sure I follow what the
consistency issue is. It seems like in most other parts of PG, types are
cast sensibly without complaint.

In 9.0 and 8.4 we can do things like:

CREATE TABLE foo (n NUMERIC(10,2));
INSERT INTO foo values (42.777777::NUMERIC(12,2));
INSERT INTO foo values (42.777777::NUMERIC(8,2));
INSERT INTO foo values (42.777777::NUMERIC(14,8));
SELECT * FROM foo
JOIN (VALUES (42.78::NUMERIC)) AS bar(m) ON foo.n = bar.m;

The values are rounded and cast; Same with varchar of various sizes.

But when returning a setof things are now strictly checked. However,
when selecting into a record PL doesn't complain if the sizes don't
match the substructure. Also curious is that single value return types
are not too particular. For example:

CREATE OR REPLACE FUNCTION check_me() RETURNS VARCHAR(2) AS
$$
BEGIN
RETURN 42.7777::NUMERIC(7,4);
END;
$$ LANGUAGE 'plpgsql';
SELECT *,pg_typeof(check_me) FROM check_me();
check_me | pg_typeof
----------+-------------------
42.7777 | character varying
(1 row)

-Noel Proffitt