postgres-xc-developers Mailing List for Postgres-XC

Hi Mason,
Sorry for delay in replying. I was busy yesterday whole day.

On Fri, Jul 29, 2011 at 6:36 PM, Michael Paquier
<mic...@gm...>wrote:

>
> Great. Is this a general solution for multi-step queries, too?
>>
> No. I don't think so. Some more general solution for multi-step queries is
> in study.
>

Mason did you mean multi-step or multi-statement queries. Let me bring up
the difference here,
Multi-step query means, the query involving multiple nodes in the plans - so
even a query like "Select * from tab1 limit 5" is a multi-step query, since
it has Limit->SeqScan plan. In the context of XC, a query can get reduced to
a single RemoteQuery, thus a mutli-step query in XC means a query which can
not be reduced to a single RemoteQuery.

So, multi-statement queries are subset of multi-step queries. From this
angle, PREPARE/EXECUTE support for multi-step queries is in place. So,
answer to your question is Yes. For multi-statement queries, the answer is
yes and no. There is some work going on about multi-statement queries, and
till that finishes, we won't be able to confirm the support for
PREPARE/EXECUTE OR for that matter any other clauses and variations of
queries, which can involve multi-statement queries. But at the current
state, the PREPARE/EXECUTE support for multi-statement queries is complete.
We may not need much changes in this support unless multi-statement queries
add their own parameters in the prepared statements.


>
>> Prepared statements are also related to stored function support.  Is
>> there any impact on support for that?
>>
> Nope. The only impact would be that there are less bugs than before in that
> area :)
>

Let me give examples here
 create or replace function bound_param_func(a int) returns int language
plpgsql as $$
declare
b int;
begin
*select val2 into b from tab1 where val = a limit 1;*
return b;
end; $$;

Earlier before 90 this used convert the SELECT query into a parameterised
query with value of a passed as parameter. But starting 90 the local
variables are not converted into parameters but they are handled by backend
through language specific hooks. So, these kind of stored functions we don't
need PREPARED query support.

create or replace function bound_param_func(a int) returns int language
plpgsql as $$
declare
b int;
begin
execute '*select val2 from tab1 where val = $1 limit 1*' into b using a;
return b;
end; $$;

The dynamic queries with parameters which have parameter values bound to
them using "USING" clause, are still treated as PREPARED queries with bound
parameters. Few examples I tried out are working as expected, so probably we
have not problems in that area. But still I am looking at those, to see the
things are kosher.

Does that answer your question?

If you know any other usages of PREPAREd statements and parameterised
PREPARE statement, please let me know. I am looking for those.

>
> --
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company