On 15/04/2010 8:05 AM, Tom Lane wrote:
"Kevin J Bluck"<kevin.bl...@netce.com> writes:
But if RETURN TABLE doesn't respect typemods, perhaps it shouldn't be
legal to specify them in that clause?
Yeah, possibly. CREATE FUNCTION has historically accepted (and then
discarded) typmod information for all function parameter and result
types; RETURNS TABLE doesn't seem particularly different from other
cases here. We could tighten that up, but again it's not clear whether
the probable ensuing application breakage would be worth the reduction
in astonishment quotient.
I do think Pavel G. has a real bug with the char thing, though.
No, it's exactly the same thing: we're accepting and then throwing away
the typmod. The fact that it's implicit rather than written out doesn't
change that.
If the function `RETURNS SETOF user_composite_type' and
user_composite_type has type length-specifiers, that data appears to be
disregarded there too, so the function can return values of
user_composite_type that violate the constraints of that type. See my
original follow-up on the bug.
That was pretty high on my personal atonishment meter. Using `SELECT ...
INTO' with the function I was able to create a table with data in it
that violated type constraints. IMO that's a bug. If functions
disregarding typmod information is the window that lets that bogus data
into the table, IMO that's a problem.
So - I do think there's a bug here, if _tables_ can be created with
character(1) fields containing three- or four-character strings.
--
Craig Ringer
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
