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
