Re: UNNEST with multiple args, and TABLE with multiple funcs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: UNNEST with multiple args, and TABLE with multiple funcs
Date
Msg-id 29388.1385140717@sss.pgh.pa.us
Whole thread Raw
In response to Re: UNNEST with multiple args, and TABLE with multiple funcs  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: UNNEST with multiple args, and TABLE with multiple funcs  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Is this intended:

[ I assume you forgot a create type footype here ]

> create function foo() returns setof footype language plpgsql
>   as $f$ begin return next row(1,true); end; $f$;

> select pg_typeof(f), row_to_json(f) from foo() with ordinality f(p,q);
>  pg_typeof |           row_to_json           
> -----------+---------------------------------
>  record    | {"p":1,"q":true,"ordinality":1}
> (1 row)

> select pg_typeof(f), row_to_json(f) from foo() f(p,q);
>  pg_typeof |   row_to_json    
> -----------+------------------
>  footype   | {"a":1,"b":true}
> (1 row)

Well, it's not insane on its face.  The rowtype of f in the first example
is necessarily a built-on-the-fly record, but in the second case using
the properties of the underlying named composite type is possible, and
consistent with what happens in 9.3 and earlier.  (Not that I'm claiming
we were or are totally consistent ...)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Next
From: Michael Meskes
Date:
Subject: Re: Building on S390