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

From Tom Lane
Subject Re: anonymous composite types for Table Functions (aka SRFs)
Date
Msg-id 21232.1027955020@sss.pgh.pa.us
Whole thread Raw
In response to Re: anonymous composite types for Table Functions (aka SRFs)  (nconway@klamath.dyndns.org (Neil Conway))
Responses Re: anonymous composite types for Table Functions (aka SRFs)  (nconway@klamath.dyndns.org (Neil Conway))
List pgsql-patches
nconway@klamath.dyndns.org (Neil Conway) writes:
>> 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...

It sounds like a way to break client-side code for little gain to me...

> 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.

The particular functions Joe is worried about (dblink and such) do not
have a fixed return type.  In any case that would be a separate
mechanism with its own issues, because we'd have to store the anonymous
type in the system catalogs.

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

> What does the 'f' indicate?

It's required by the SQL alias syntax.

>> 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?

Why?  That just deviates even further from the spec syntax.

            regards, tom lane

pgsql-patches by date:

Previous
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: Re: anonymous composite types for Table Functions (aka SRFs)
Next
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: Re: anonymous composite types for Table Functions (aka SRFs)