2010/4/15 Tom Lane <tgl@sss.pgh.pa.us>:
> "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. =C2=A0CREATE 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. =C2=A0We could tighten that up, but again it's not clear whet=
her
> the probable ensuing application breakage would be worth the reduction
> in astonishment quotient.
I think, so RETURNS TABLE can be modified for returning typmode
without significant problems - this function is called in table
context and I don't see any problematic use case.
Pavel
>
>> 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. =C2=A0The fact that it's implicit rather than written out doe=
sn't
> change that.
>
> char would be a particularly nasty case if we did reject typmod
> specifications for function arguments/results, because there is no
> standard syntax for specifying char without a defined max length.
> You'd have to fall back to writing "bpchar", which isn't going to
> make people happy either...
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0regards, tom lane
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
