From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Simonetti <marks(at)opalsoftware(dot)co(dot)uk> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Function parameter type precision modifiers ignored. |
Date: | 2015-02-06 21:57:04 |
Message-ID: | 4295.1423259824@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Mark Simonetti <marks(at)opalsoftware(dot)co(dot)uk> 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.
There's been some talk of rejecting syntax like the above, because we
get bug reports like this once or twice a year, so obviously a lot of
people are confused about what happens.
The odds of actually enforcing such typmods anytime in the near future
are not distinguishable from zero, but we could make CREATE FUNCTION
throw an error.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G Johnston | 2015-02-06 22:05:48 | Re: Function parameter type precision modifiers ignored. |
Previous Message | barrera | 2015-02-06 20:50:09 | BUG #12743: error in xml conversion |