Re: Returning Composite Types from C functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Returning Composite Types from C functions
Date
Msg-id 12470.1119102867@sss.pgh.pa.us
Whole thread Raw
In response to Re: Returning Composite Types from C functions  ("John Hansen" <john@geeknet.com.au>)
List pgsql-hackers
"John Hansen" <john@geeknet.com.au> writes:
>>> SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS 
>>> b) AS a; 
>>> Or am I missing something?
>> 
>> Try it ;-)

> Yes, it worked for me,... 

It depends on your test case, but in many situations the planner will
flatten that into the same result as the other.  The basic problem is
that "(foo).*" is expanded to "(foo).f1, (foo).f2, ..." which is OK if
foo is just a variable referring to a subquery output --- but if the
subquery gets flattened into the parent then your function appears
textually multiple times in the resulting query.

There's been some discussion of disabling flattening when the subquery
output targetlist contains any volatile functions, but that seems like
rather a performance-losing answer.  It doesn't completely address the
complaint anyway since even a non-volatile function might be expensive
to compute.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "John Hansen"
Date:
Subject: Re: Returning Composite Types from C functions
Next
From: Robert Treat
Date:
Subject: Re: [PATCHES] Escape handling in strings