|
|
Subject: functions are returns columns
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 11/10/2007 2:46:35 PM
Gregory Stark <stark@enterprisedb.com> writes:
> You're almost there:
> CREATE FUNCTION getfoo (IN int, OUT int, OUT int) returns setof record(int,int) AS $$
> SELECT fooid, foosubid FROM foo WHERE fooid = $1;
> $$ LANGUAGE SQL;
Not quite --- it's just "returns setof record". The output column types
are defined by the OUT parameters. The only reason you need the returns
clause is to have a place to stick the "setof" specification ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Subject: functions are returns columns
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 11/10/2007 6:14:50 PM
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> Not quite --- it's just "returns setof record".
> I did test my example before posting it:
> postgres=# postgres=# CREATE or replace FUNCTION getfoo (IN int, OUT int, OUT int) returns setof record(int,int)AS $$
> SELECT 1,2 union all select 2,3;
> $$ LANGUAGE SQL;
Interesting --- if you try it in anything older than 8.3, it will fail.
What is happening here is that the "(int,int)" is being taken as a
typmod (per Teodor's work to allow typmods for all data types), and
apparently in this path we never check to see if it's a *valid* typmod.
Now typmods are always discarded from function argument and result
types, but it seems like we'd better validate that they're legal for the
datatype anyway. Otherwise there will be confusion of just this sort.
Comments, objections?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
|