Tom Lane-2 wrote
> Mark Simonetti <
> marks@.co
> > writes:
>> I don't know if this is a bug as such, but the behaviour certainly
>> confused me for a while : -
>
>> Given the following PostgreSQL functions:
>
>> CREATE OR REPLACE FUNCTION fn_dtm (
>> dtm timestamptz(0))
>> RETURNS void AS $$
>> BEGIN
>> RAISE NOTICE 'fn: %, %', dtm, dtm::timestamptz(0);
>> END;
>> $$ LANGUAGE plpgsql;
>
>> CREATE OR REPLACE FUNCTION fn_num (
>> num numeric(5, 2))
>> RETURNS void AS $$
>> BEGIN
>> RAISE NOTICE 'num: %, %', num, num::numeric(5, 2);
>> END;
>> $$ LANGUAGE plpgsql;
>
>> Would you expect the output of these functions to show the result as per
>> the type declared in the function parameter?
>
> Attributes applied to function parameter types --- or result types for
> that matter --- are entirely ignored by Postgres; only the base type
> matters. This is documented.
http://www.postgresql.org/docs/9.4/interactive/sql-createfunction.html
@ Notes
First Paragraph
Maybe it would be more obvious in the section detailing "argtype"...but its
not like its buried deep in the documentation. The bigger problem is
understanding exactly what that notes means in reality. Often that means
getting bit by the behavior first and then reading about what just bit you.
Happens to all of us.
I'm for the idea of issuing a syntax error upon seeing "type()" in general
but not strongly since perfectly valid code (often back-stopped by table
constraints) currently works and would otherwise have no reason to change
other than to conform to this decision.
David J.
--
View this message in context:
http://postgresql.nabble.com/Function-parameter-type-precision-modifiers-ignored-tp5836988p5837000.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.