From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Joe Conway" <mail(at)joeconway(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: anonymous composite types for Table Functions (aka SRFs) |
Date: | 2002-07-25 07:02:30 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961E2D@m0114.s-mxs.net |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Now when creating a function you can do:
> > CREATE FUNCTION foo(text) RETURNS setof RECORD ...
> >
> > And when using it you can do, e.g.:
> > SELECT * from foo(sqlstmt) AS (f1 int, f2 text, f3 timestamp)
>
> Why is there the requirement to declare the type at SELECT
> time at all? Why
> not just take what you get when you run the function?
Yea, that would imho be ultra cool, but I guess the parser/planner must already
know the expected column names and types to resolve conflicts, do a reasonable
plan and use the correct type conversions.
Maybe the AS (...) could be optional, and if left out, the executor would need
to abort iff duplicate colnames (from a joined table) or non binary compatible
conversions would be involved. A "select * from func();" would then always work,
but if you add "where x=5" the executor might need to abort.
Looks like a lot of work though.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-07-25 07:16:14 | Re: Proposal: anonymous composite types for Table Functions (aka SRFs) |
Previous Message | Joe Conway | 2002-07-25 07:00:48 | Re: Proposal: anonymous composite types for Table Functions |