2010/4/15 Tom Lane <t...@sss.pgh.pa.us>: > "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 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. The fact that it's implicit rather than written out doesn'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... > > regards, 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 > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
