Re: Returning Composite Types from C functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "John Hansen" <john(at)geeknet(dot)com(dot)au>
Cc: "Michael Fuhr" <mike(at)fuhr(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Returning Composite Types from C functions
Date: 2005-06-18 13:54:27
Message-ID: 12470.1119102867@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"John Hansen" <john(at)geeknet(dot)com(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2005-06-18 14:07:54 Re: [PATCHES] Escape handling in strings
Previous Message Andreas Pflug 2005-06-18 13:53:53 Re: default database creation with initdb