Re: anonymous composite types for Table Functions (aka - Mailing list pgsql-patches

Neil Conway wrote:
> On Sun, Jul 28, 2002 at 10:24:34PM -0700, Joe Conway wrote:
>>Attached are two patches to implement and document anonymous composite
>>types for Table Functions, as previously proposed on HACKERS.
>
> Nice work!

Thanks!


>>1. Creates a new pg_type typtype: 'p' for pseudo type (currently either
>>    'b' for base or 'c' for catalog, i.e. a class).
> I think you mentioned that typtype could be renamed to typkind -- that
> sounds good to me...

I didn't get any feedback on that idea, so I decided to leave it alone
for now.


>>When creating a function you can do:
>>    CREATE FUNCTION foo(text) RETURNS setof RECORD ...
>>When using it you can do:
>>    SELECT * from foo(sqlstmt) AS (f1 int, f2 text, f3 timestamp)
>
> Is there a reason why you can't specify the return type in the function
> declaration? ISTM that for most functions, the 'AS' clause will be the
> same for every usage of the function.

Ahh, that's the next proposal ;-)

For functions such as dblink and crosstab, mentioned in the original
post, the 'AS' clause needed may be *different* every time the function
is called.

But specifying the composite type on function declaration would also be
a good thing. In order to do that we first need to be able to create
named, but stand-alone, composite types. Once we can do that, then
creating an implicit named composite type (with a system generated name)
on function creation should be easy. I plan to follow up with a specific
proposal this week.


> On a related note, it is possible for the table function to examine the
> attributes it has been asked to return, right? Since the current patch
> requires that every call specify the return type, it might be possible
> to take advantage of that to provide semi-"polymorphic" behavior
> (i.e. the function behaves differently depending on the type of data
> the user asked for)

Hmmm, I'll have to think about that. I don't think the current
implementation has a way to pass that information to the function. We
would need to modify fcinfo to carry along the run-time tupdesc if we
wanted to do this. Not sure how hard it would be to do -- I'll have to look.

Note that this syntax is only required when the function has been
declared as returning RECORD -- if the function is declared to return
some named composite type, it doesn't need or use the runtime specified
structure. In that case the function *can* derive it's own tupdesc using
the function return type to get the return type relid. That is how the
submitted crosstab() function works.


>>    SELECT * from foo(sqlstmt) AS f(f1 int, f2 text, f3 timestamp)
>
>
> What does the 'f' indicate?

'f' here is the table alias. Probably would have been more clear like this:

    SELECT f.* from foo(sqlstmt) AS f(f1 int, f2 text, f3 timestamp)



>>    SELECT * from foo(sqlstmt) f(f1 int, f2 text, f3 timestamp)
> This form of the syntax seems a bit unclear, IMHO. It seems a bit
> like two function calls. Can the 'AS' be made mandatory?

Well this is currently one acceptable syntax for an alias clause, e.g.
    SELECT * from foo f(f1, f2, f3);

is allowed. I was trying to be consistent. Anyone else have thoughts on
this?

Thank you for your review and comments!

Joe