I think the same way :). But as I mentioned in the first letter I'm not a C guy. So I wonder why doesn't postgres store hashes for all queries and misses parsing step if not needed like Oracle does?
On 8/3/07, Sibte Abbas <[EMAIL PROTECTED]> wrote: > > On 8/3/07, Sergey Moroz <[EMAIL PROTECTED]> wrote: > > No that is not I meant. The problem in Prepared statements is in that > you > > should determine SQL inside the function. I want to pass a query as a > > parameter, as well as query parameters. > > For example (I want to create a function like the following): > > > > select * > > from exec_query( > > /*query text => */ 'select f1, f2 from > table > > where f3 = $1' , > > /*param1 => */ 1::integer > > ) > > as (f1 integer, f2 text) > > > > so function exec_query got a query text as parameter, query parameters, > > executed it and returned result as SETOF. In case of such a query had > been > > executed at least once, prepare step should be excluded (stored > execution > > plan should be used). > > > > In this case you need to store query text along with its plan name. > This will allow you to simply execute the plan each time a previously > parsed/planned query is executed. > > However storing raw queries can be a *very* expensive operation, not > to mention the high cost of performing comparison on them. Due to the > associated cost, I'll > recommend using(and storing) hashes for query text. > > If I were you, i'll write the hash calculation and storage and > retrieval functions in C and the top level function in Plpgsql. > > Hope that helps. > > regards, > -- Sibte > -- Sincerely, Sergey Moroz
