> > ... 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
> > 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
> 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
> 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.
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2005-01-26 15:02:07|
|Subject: Re: bug w/ cursors and savepoints|
|Previous:||From: noman naeem||Date: 2005-01-26 13:20:51|
|Subject: Re: how to add a new column in pg_proc table |
pgsql-odbc by date
|Next:||From: Joost Kraaijeveld||Date: 2005-01-26 16:59:50|
|Subject: ODBC bug?|
|Previous:||From: Bojidar Mihajlov||Date: 2005-01-26 11:26:25|
|Subject: Re: RQ: Prepared statements used by multiple connections|