On 01/12/2010 06:43 AM, Andrew Chernow wrote:
>>
>> What is the point of this discussion? We're not going to remove the
>> facility for composite types, regardless of whether or not some people
>> regard them as unnecessary. And "a name that better suits the task" is
>> not to be sneered at anyway.
>>
>
> I never asked for anything to be removed nor do I sneer :) Honestly, I
> was only trying to understand why it existed.
It exists because once upon a time when SRFs were first created, and you
were using a function returning SETOF RECORD, you would either have to
enumerate every column definition in your query, or create a "dummy"
table that had the right columns/types to match your return tuple.
That solution was generally viewed as grotty -- the former is a lot of
typing and clutter, and the latter creates a table with the only purpose
being to get the needed composite type created. Therefore we added the
ability to skip the table creation and just produce the needed composite
type.
HTH
Joe
