Skip site navigation (1) Skip section navigation (2)

Re: Bug in CREATE FUNCTION with character type (CONFIRMED BUG)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin J Bluck" <technology(at)netce(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bug in CREATE FUNCTION with character type (CONFIRMED BUG)
Date: 2010-04-15 00:05:58
Message-ID: 18691.1271289958@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Kevin J Bluck" <kevin(dot)bluck(at)netce(dot)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.

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

In response to

Responses

pgsql-bugs by date

Next:From: Alex Soto PaezDate: 2010-04-15 00:15:06
Subject: BUG #5423: problems installing postgresql-8.4 deleted folder / .s.PGSQL.lock not initiate the connecti
Previous:From: Alex Soto PaezDate: 2010-04-15 00:02:15
Subject: BUG #5422: problems installing postgresql-8.4 deleted folder / .s.PGSQL.lock not initinot initiate the connecti

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group