Thread: Dynamic/polymorphic record/composite return types for C user-defined-functions

Dynamic/polymorphic record/composite return types for C user-defined-functions

From
Stephen Scheck
Date:
On Tue, Apr 2, 2013 at 10:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
if you just write

        SELECT function_returning_record(...) FROM ...

and not

        SELECT (function_returning_record(...)).* FROM ...

I think that the run-time-blessed-record-type hack will work okay.
Of course that greatly limits what you can do with the result in SQL,
but if you just need to ship it to a client it might be all right.

                        regards, tom lane

Indeed, one of the primary concerns is the ability to query against the returned record(s):

    SELECT * FROM (SELECT (info(lo_oid_col)).* FROM table_with_lo_oids) s1 WHERE
        s1.some_property = <some_value>

I'm thinking a solution might be to create a generic "anynumber" type which records its "instant"
type along with a slate of CREATE CASTs to go back and forth between base numeric types. For example:

    CREATE TYPE number; -- avoid calling it "anynumber" since it's not really polymorphic in the postgres sense
    CREATE FUNCTION some_func_returning_number(IN some_type some_param) RETURNS number ...

    -- foo knows what type it is and when its CAST function is called from context, it calls
    -- a built-in CAST function to go from its instance type to the contextual type (integer here):
    SELECT some_func_returning_number(foo) + 1::integer FROM bar;

Do you see any architectural/implementation pitfalls to such an approach? It doesn't seem like it would entail
a great deal of additional code.

Thanks,
-Steve