Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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



pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2005-01-26 15:02:07
Subject: Re: bug w/ cursors and savepoints
Previous:From: noman naeemDate: 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 KraaijeveldDate: 2005-01-26 16:59:50
Subject: ODBC bug?
Previous:From: Bojidar MihajlovDate: 2005-01-26 11:26:25
Subject: Re: RQ: Prepared statements used by multiple connections

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group