On Feb 17, 9:59 am, b...@wards.net (Bill Ward) wrote:
>
> You can be reasonably safe using inline params like that if you're careful
> to make sure $q contains only the sort of characters that make sense for
> your app, and/or if $q is quoted properly. You can use a regex to test that
> it is only
On Fri, 17 Feb 2012 11:18:39 -0600
Puneet Kishor wrote:
> >> query 2 is at least an order of magnitude slower than query 1
>
> Now that I know the reason behind this, thanks to all of you, I have
> decided to stick with inline params `LIKE $q` instead of bind values.
> I am not too worried about
On Fri, Feb 17, 2012 at 9:18 AM, Puneet Kishor wrote:
>
> On Feb 17, 2012, at 11:05 AM, Greg Sabino Mullane wrote:
>
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: RIPEMD160
> >
> >
> >> query 2 is at least an order of magnitude slower than query 1
> >
> > To follow up on this, the current
On Feb 17, 2012, at 11:05 AM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>> query 2 is at least an order of magnitude slower than query 1
>
> To follow up on this, the current best practice for handling this
> is to prepare two statements, and hav
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> query 2 is at least an order of magnitude slower than query 1
To follow up on this, the current best practice for handling this
is to prepare two statements, and have your app use the correct one.
One could be prepared with pg_server_prepar
I've just uploaded DBD::ODBC 1.34_5 to the CPAN.
I know I often say this but my intention is to release this as 1.35 soon unless
any major issues are found. The total changes since the last full release are:
=head2 Changes in DBD::ODBC 1.34_5 February 17 2012
[BUG FIXES]
* The 40UnicodeRo
