Re: [HACKERS] RQ: Prepared statements used by multiple connections

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

Browse pgsql-hackers by date

  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

Browse pgsql-odbc by date

  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