Tom,
Thanks again for the reply.
We're calling the 'function' from a 4gl program - I'm just trying the 'Record' type route to make sure that the 4gl understands the returned type. If not, then named row types will have to be the option.
Cheers again.
On Mon, 2004-08-09 at 15:23, Tom Lane wrote:
Steve Tucknott <steve@retsol.co.uk> writes:
> Does the 'rowtype' have to exist as a definition in the database?
In the form I showed, yes.
> Would returning a record type work -
Only if you're prepared to specify the actual record type in the calling
query. The point is that in
select * from myfunc(...);
the parser has to have some way of understanding what * expands to,
and it needs the info in advance of calling the function. So you
either need to return a named rowtype, or return record and specify
what you're expecting in the call. From memory it's something like
select * from myfunc(...) AS (f1 int, f2 text, ...);
but see the docs. In practice I think the named rowtype is easier in
99% of cases. The returns-record case is really meant for functions
that can actually return different rowtypes depending on the parameters
they are given, like dblink() does. If you're thinking of doing something
like that, you probably shouldn't be asking about it on the novice list ;-)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Regards,
Steve Tucknott
ReTSol Ltd
DDI: 01903 828769
|
