Re: anonymous composite types for Table Functions (aka SRFs)

I am sorry but I am unable to apply this patch because of the DROP
COLUMN patch that was applied since you submitted this.

It had rejections in gram.y and parse_relation.c, but those were easy to
fix. The big problem is pg_proc.c, where the code changes can not be
merged.

I am attaching the rejected part of the patch. If you can send me a
fixed version of just that change, I can commit the rest.

Thanks.

---------------------------------------------------------------------------

Joe Conway wrote:
> Attached are two patches to implement and document anonymous composite
> types for Table Functions, as previously proposed on HACKERS. Here is a
> brief explanation:
>
> 1. Creates a new pg_type typtype: 'p' for pseudo type (currently either
> 'b' for base or 'c' for catalog, i.e. a class).
>
> 2. Creates new builtin type of typtype='p' named RECORD. This is the
> first of potentially several pseudo types.
>
> 3. Modify FROM clause grammer to accept:
> SELECT * FROM my_func() AS m(colname1 type1, colname2 type1, ...)
> where m is the table alias, colname1, etc are the column names, and
> type1, etc are the column types.
>
> 4. When typtype == 'p' and the function return type is RECORD, a list
> of column defs is required, and when typtype != 'p', it is disallowed.
>
> 5. A check was added to ensure that the tupdesc provide via the parser
> and the actual return tupdesc match in number and type of attributes.
>
> 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)
> or
> SELECT * from foo(sqlstmt) AS f(f1 int, f2 text, f3 timestamp)
> or
> SELECT * from foo(sqlstmt) f(f1 int, f2 text, f3 timestamp)
>
> Included in the patches are adjustments to the regression test sql and
> expected files, and documentation.
>
> If there are no objections, please apply.
>
> Thanks,
>
> Joe
>
> p.s.
> This potentially solves (or at least improves) the issue of builtin
> Table Functions. They can be bootstrapped as returning RECORD, and
> we can wrap system views around them with properly specified column
> defs. For example:
>
> CREATE VIEW pg_settings AS
> SELECT s.name, s.setting
> FROM show_all_settings()AS s(name text, setting text);
>
> Then we can also add the UPDATE RULE that I previously posted to
> pg_settings, and have pg_settings act like a virtual table, allowing
> settings to be queried and set.
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026