Skip site navigation (1) Skip section navigation (2)

Re: Passing arguments to views

From: Mark Dilger <pgsql(at)markdilger(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Passing arguments to views
Date: 2006-02-03 18:46:07
Message-ID: 43E3A4EF.2070005@markdilger.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Chris Campbell <chris(at)bignerdranch(dot)com> 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?


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-02-03 18:54:37
Subject: Re: Passing arguments to views
Previous:From: Bruce MomjianDate: 2006-02-03 18:40:01
Subject: Re: [PATCHES] Fix for running from admin account on win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group