Tom Lane wrote:
Chris Campbell <[EMAIL PROTECTED]> writes:
True, as long as there's a hook to do the inlining/rewriting before
the query's planned. I guess we can see function calls at the parse
stage, check to see if they're SQL functions or not, grab the prosrc,
do the substitution, then re-parse?
pull_up_subqueries in prepjointree.c would be the appropriate place
I think: if it's an RTE_FUNCTION RTE, look to see if function is SQL
and has the other needed properties, if so replace it by an RTE_SUBQUERY
RTE with the correct subquery, then recurse to try to flatten the
subquery. (Note: I'm in the middle of hacking that code to flatten
UNION subqueries, so you might want to wait till I commit before
starting on a patch ;-))
If we are talking about inserting the function definition into the query as a
subquery and then letting the parser treat it as a subquery, then I see no
reason to use either the existing function or view subsystems. It sounds more
like we are discussing a macro language.
CREATE MACRO foo(bar,baz) AS $$
select a from b where b > bar and b < baz
$$;
Then when you query
SELECT * FROM foo(1,7) AS f WHERE f % 7 = 3
you get a macro expansion as such:
SELECT * FROM (a from b where b > bar and b < baz) AS f WHERE f % 7 = 3
Then whatever optimizations the query planner can manage against a subquery will
work for macros as well.
Thoughts?
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
