Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I want to address the issue that calling a record-returning function
> always requires specifying a result column list, even though there are
> cases where the function could be self-aware enough to know the result
> column list of a particular call. For example, most of the functions in
> contrib/tablefunc are like that.
Seems like a reasonable goal.
> SQL:2016 has a feature called polymorphic table functions (PTF) that
> addresses this. The full PTF feature is much larger, so I just carved
> out this particular piece of functionality. Here is a link to some
> related information:
> https://modern-sql.com/blog/2018-11/whats-new-in-oracle-database-18c#ptf
> The idea is that you attach a helper function to the main function. The
> helper function is called at parse time with the constant arguments of
> the main function call and can compute a result row description (a
> TupleDesc in our case).
> Example from the patch:
> CREATE FUNCTION connectby_describe(internal)
> RETURNS internal
> AS 'MODULE_PATHNAME', 'connectby_describe'
> LANGUAGE C;
> CREATE FUNCTION connectby(text,text,text,text,int,text)
> RETURNS setof record
> DESCRIBE WITH connectby_describe
> AS 'MODULE_PATHNAME','connectby_text'
> LANGUAGE C STABLE STRICT;
> (The general idea is very similar to Pavel's patch "parse time support
> function"[0] but addressing a disjoint problem.)
Hm. Given that this involves a function-taking-and-returning-internal,
I think it's fairly silly to claim that it is implementing a SQL-standard
feature, or even a subset or related feature. Nor do I see a pathway
whereby this might end in a feature you could use without writing C code.
That being the case, I'm not in favor of using up SQL syntax space for it
if we don't have to. Moreover, this approach requires a whole lot of
duplicative-seeming new infrastructure, such as a new pg_proc column.
And you're not even done yet --- where's the pg_dump support?
I think we'd be better off to address this by extending the existing
"support function" infrastructure by inventing a new support request type,
much as Pavel's patch did. I've not gotten around to reviewing the latest
version of his patch, so I'm not sure if it provides enough flexibility to
solve this particular problem, or if we'd need a different request type
than he proposes. But I'd rather go down that path than this one.
It should provide the same amount of functionality with a whole lot less
overhead code.
regards, tom lane