On Tue, Apr 2, 2013 at 10:55 AM, Tom Lane <t...@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
