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
