From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
Cc: | Andrej <andrej(dot)groups(at)gmail(dot)com>, JP Fletcher <jpfletch(at)ca(dot)afilias(dot)info>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: prepared statements and DBD::Pg |
Date: | 2009-05-08 14:27:25 |
Message-ID: | 20090508142725.GF18067@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, May 08, 2009 at 09:44:56AM +0100, Tim Bunce wrote:
> 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?
That's not the kind of code it broke.
> 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?
They need to know what kinds of SQL statements are valid, full stop.
> From the DBI's perspective, $dbh->prepare($valid_sql_statement)
> should always work.
Yes, it should, and unless and until PostgreSQL's parser becomes an
exportable library, there will be no way to establish that on the
client side.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-05-08 14:36:52 | Re: Remote access |
Previous Message | Andrew Gould | 2009-05-08 14:20:38 | Re: Remote access |