On 15/04/2010 8:05 AM, Tom Lane wrote:
> "Kevin J Bluck"<kevin.bluck@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
