Re: Select + Functions + Composite Types: Behavior - Mailing list pgsql-general

From David Johnston
Subject Re: Select + Functions + Composite Types: Behavior
Date
Msg-id 01ea01cbcb0f$81de5250$859af6f0$@yahoo.com
Whole thread Raw
In response to Re: Select + Functions + Composite Types: Behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom,

BTW, with the quick response you provided (THANKS!) I probably should have
pinged the list sooner in my search...

David J.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Saturday, February 12, 2011 5:33 PM
To: David Johnston
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Select + Functions + Composite Types: Behavior

"David Johnston" <polobo@yahoo.com> writes:
> If I put a function that returns a composite type into the FROM clause
> of a SELECT query (and it - the function - is the only source for the
> query) the "*" select list expands so that there is a single record
> for each component of the composite type.

> SELECT * FROM compositereturningfunction() Yields -> 2 columns (one
> for id and one for data)

> I've read quite a bit about plpgsql and composite types and do not
> recall anything about this specific default behavior and methods to
> force
> (workaround) to the other behavior.

It's just like tables. Try

    select x from compositereturningfunction() x

            regards, tom lane


pgsql-general by date:

Previous
From: "David Johnston"
Date:
Subject: Re: Select + Functions + Composite Types: Behavior
Next
From: "David Johnston"
Date:
Subject: Re: Select + Functions + Composite Types: Behavior