On Thu, May 07, 2009 at 06:08:12PM -0700, David Fetter wrote:
> On Fri, May 08, 2009 at 01:02:04AM +0100, Tim Bunce wrote:
> > On Thu, May 07, 2009 at 06:50:11AM -0700, David Fetter wrote:
> > > On Thu, May 07, 2009 at 02:31:08PM +0100, Tim Bunce wrote:
> > > > On Thu, May 07, 2009 at 04:54:06AM +1200, Andrej wrote:
> > > > >
> > > > > WARNING: DBD::Pg now (as of version 1.40) uses true prepared
> > > > > statements by sending them to the backend to be prepared by
> > > > > the Postgres server. Statements that were legal before may no
> > > > > longer work.
> > > >
> > > > Sure seems like a bug, or at best a misfeature, that DBD::Pg
> > > > doesn't simply fallback to client-side prepare when a
> > > > server-side prepare can't be performed. I believe DBD::mysql
> > > > does that.
> > >
> > > It's a safety feature. :)
> >
> > Er. I see the smiley but I'm not sure if that's a joke. Can you
> > expand?
>
> It's not a joke. Client-side prepare is essentially creating a
> duplicate code path and hoping that it does exactly the same thing
> that the server-side one does, and this in a context of controlling
> access.
>
> If PostgreSQL's parser, etc., were in the form of exportable
> libraries, that would be very nice, but until then, making server-side
> prepare the only kind is just jungle caution.
So you're okay with breaking previously working, and prefectly valid, DBI code?
And you're okay with forcing application writers to "know" which kinds
of sql statements can, or can't, be server-side prepared by the
particular version of postgress they're talking to?
From the DBI's perspective, $dbh->prepare($valid_sql_statement) should
always work.
Tim.
