On Fri, Aug 12, 2011 at 12:01 PM, George MacKerron
<g.j.macker...@lse.ac.uk> wrote:
> On 12 Aug 2011, at 17:43, Merlin Moncure wrote:
>
>> you can't have it both ways. at the time the function call is
>> executed, the return type/fields must be known.  you can do this by
>> either a. explicitly defining the function return type or b.
>> describing the function return type in the function call, or c. use a
>> generic type to hold the output record structure which can be
>> parsed/dealt with later, like text or hstore.
>
> Thanks.
>
> I'm trying to do your option (a) -- defining the function return type.
>
> But I want to do this by referring to an existing table type -- which I know 
> the returned fields must match -- rather than laboriously retype the field 
> definition list for that table.
>
> The problem is that I can't make the database accept the table type as a 
> field definition list, when that seems like a perfectly sensible (and in this 
> case much more convenient) way to define the fields that will be returned.
>
> (With apologies for thoughtless top-posting in reply to Ray's earlier 
> message).

yes -- you should be able to do this but you can't since there is no
way to transform the return type from record to type t outside the
function call.  your best bet is to apply method c. above:

postgres=# create type t as (a int, b int, c int);
CREATE TYPE

postgres=# create or replace function r() returns setof text as $$
begin
  return query select row(1,2,3)::t::text;
end; $$ language plpgsql;
CREATE FUNCTION

postgres=# select r();
    r
---------
 (1,2,3)
(1 row)

Time: 18.000 ms
postgres=# select r()::t;
    r
---------
 (1,2,3)
(1 row)

Time: 0.000 ms
postgres=# select (r()::t).*;
 a | b | c
---+---+---
 1 | 2 | 3
(1 row)

as a bonus you can call the function more flexibly since it returns a scalar.

merlin

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to