From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, <pgsql-odbc(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] RQ: Prepared statements used by multiple connections |
Date: | 2005-01-26 13:26:19 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3412A75E6@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-odbc |
> > ... a prepared version that is local to the backend that invokes the
> > function, yes (i.e. it will be planned once per backend). So ISTM
this
> > is equivalent functionality to what you can get using PREPARE or the
> > extended query protocol.
>
> Are you sure it's only per-backend? I thought I tested it and it
seemed
> to prepare it everywhere... oh well.
Plpgsql functions at the least are compiled by each backend. I take
advantage of this...I use schemas and I don't have to keep a copy of the
function for each dataset. I think vanilla sql functions might be
different.
> Either way, it avoids the problem with prepared queries in that you
> cannot know in advance if your query has already been prepared or not.
Yep. I like things the way they are, but I can feel the pain of
applications that don't (or can't) keep connections open.
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-01-26 15:02:07 | Re: bug w/ cursors and savepoints |
Previous Message | noman naeem | 2005-01-26 13:20:51 | Re: how to add a new column in pg_proc table |
From | Date | Subject | |
---|---|---|---|
Next Message | Joost Kraaijeveld | 2005-01-26 16:59:50 | ODBC bug? |
Previous Message | Bojidar Mihajlov | 2005-01-26 11:26:25 | Re: RQ: Prepared statements used by multiple connections |