LIMIT ?,? statement

* Fixed bug where strings that were used in numeric
context were not getting quoted on execute(). Now all
parameters are bound as varchar by default.

**NOTE** this is a change in behavior that MAY cause problems
with some SQL statements. If quoted integers, for example,
cause any problems, use bind_param(, SQL_INTEGER) to
force a column to be bound as an integer.

Yes, it MAKES problems.
All queries with 'LIMIT ?,?' FAILS now,
because modern versions of MySQL fails to execute statements
with quoted LIMIT ranges.

Anyone should be able to repeat the bug with
the latest stable or development version of MySQL Server.

You want to force EVERYONE in this world to change their
coding style and STOP using convenient wrappers
like $dbh->selectrow_hashref( $statement, undef, @params ) ?

You wish that EVERYONE should use bind_param(..., ..., SQL_INTEGER)
everythere because of this STUPID change?

Please, FIX THIS.

PS: Sorry, I can't talk about this without emotions
because I'm very tired of this.

--

Regards, Walery Studennikov,
WebNames.Ru technical support

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

Walery Studennikov wrote:

> All queries with 'LIMIT ?,?' FAILS now,
> because modern versions of MySQL fails to execute statements
> with quoted LIMIT ranges.

It should be noted, that almost definitely you cannot expect this to work
with other drivers/databases as well. Likewise, you cannot expect that other
drivers/databases are able to submit table/column names via placeholders.

In particular, this will most likely *not* work with later version of
*MySQL* that *are* supporting placeholders on the server side. (No doubt,
we all want to use MySQL's server side placeholders if we can, do we?) In
other words, I would consider these to be questionable features and do not
see it as a reason to restore the old behaviour.


Jochen


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

Walery Studennikov wrote:

> All queries with 'LIMIT ?,?' FAILS now,
> because modern versions of MySQL fails to execute statements
> with quoted LIMIT ranges.

It should be noted, that almost definitely you cannot expect this to work
with other drivers/databases as well. Likewise, you cannot expect that other
drivers/databases are able to submit table/column names via placeholders.

In particular, this will most likely *not* work with later version of
*MySQL* that *are* supporting placeholders on the server side. (No doubt,
we all want to use MySQL's server side placeholders if we can, do we?) In
other words, I would consider these to be questionable features and do not
see it as a reason to restore the old behaviour.


Jochen


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, Jan 16, 2004 at 09:46:40AM +0100, Jochen Wiedmann wrote:
> Walery Studennikov wrote:
>
> >All queries with 'LIMIT ?,?' FAILS now,
> >because modern versions of MySQL fails to execute statements
> >with quoted LIMIT ranges.
>
> It should be noted, that almost definitely you cannot expect this to work
> with other drivers/databases as well. Likewise, you cannot expect that
> other drivers/databases are able to submit table/column names via
> placeholders.

And what?
It is very convenient and practical for many developers.
If I _wish_ to use it for my convenience and if I don't want
to port my programs to other DBMS, why somebody forbids to use
those useful features for me?

> In particular, this will most likely *not* work with later version of
> *MySQL* that *are* supporting placeholders on the server side. (No doubt,
> we all want to use MySQL's server side placeholders if we can, do we?) In
> other words, I would consider these to be questionable features and do not
> see it as a reason to restore the old behaviour.

IMHO supporting placeholders on the server side should be optional
there should be an option for developers to turn it ON and OFF.
If "questionable features" is more important for me,
I should be able to turn server side placeholders OFF and
use those "questionable features".

--

Regards, Walery Studennikov,
WebNames.Ru technical support

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, Jan 16, 2004 at 09:46:40AM +0100, Jochen Wiedmann wrote:
> Walery Studennikov wrote:
>
> >All queries with 'LIMIT ?,?' FAILS now,
> >because modern versions of MySQL fails to execute statements
> >with quoted LIMIT ranges.
>
> It should be noted, that almost definitely you cannot expect this to work
> with other drivers/databases as well. Likewise, you cannot expect that
> other drivers/databases are able to submit table/column names via
> placeholders.

And what?
It is very convenient and practical for many developers.
If I _wish_ to use it for my convenience and if I don't want
to port my programs to other DBMS, why somebody forbids to use
those useful features for me?

> In particular, this will most likely *not* work with later version of
> *MySQL* that *are* supporting placeholders on the server side. (No doubt,
> we all want to use MySQL's server side placeholders if we can, do we?) In
> other words, I would consider these to be questionable features and do not
> see it as a reason to restore the old behaviour.

IMHO supporting placeholders on the server side should be optional
there should be an option for developers to turn it ON and OFF.
If "questionable features" is more important for me,
I should be able to turn server side placeholders OFF and
use those "questionable features".

--

Regards, Walery Studennikov,
WebNames.Ru technical support

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

Walery Studennikov wrote:

> And what?
> It is very convenient and practical for many developers.
> If I _wish_ to use it for my convenience and if I don't want
> to port my programs to other DBMS, why somebody forbids to use
> those useful features for me?

And if I as the drivers developer _wish_ to use to be as portable as
possible to other drivers, what forbids me to remove such a feature? :-)

Sorry, but my argument was simply that I consider upwards portability in
that point as less important. That's my view and you have a different. Fine
for me. It is simply that my opinion counts as well as yours.


> IMHO supporting placeholders on the server side should be optional
> there should be an option for developers to turn it ON and OFF.
> If "questionable features" is more important for me,
> I should be able to turn server side placeholders OFF and
> use those "questionable features".

Volunteer for a patch? :-)


Jochen


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

Walery Studennikov wrote:

> And what?
> It is very convenient and practical for many developers.
> If I _wish_ to use it for my convenience and if I don't want
> to port my programs to other DBMS, why somebody forbids to use
> those useful features for me?

And if I as the drivers developer _wish_ to use to be as portable as
possible to other drivers, what forbids me to remove such a feature? :-)

Sorry, but my argument was simply that I consider upwards portability in
that point as less important. That's my view and you have a different. Fine
for me. It is simply that my opinion counts as well as yours.


> IMHO supporting placeholders on the server side should be optional
> there should be an option for developers to turn it ON and OFF.
> If "questionable features" is more important for me,
> I should be able to turn server side placeholders OFF and
> use those "questionable features".

Volunteer for a patch? :-)


Jochen


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, Jan 16, 2004 at 10:28:58AM +0100, Jochen Wiedmann wrote:
> Walery Studennikov wrote:
>
> >And what?
> >It is very convenient and practical for many developers.
> >If I _wish_ to use it for my convenience and if I don't want
> >to port my programs to other DBMS, why somebody forbids to use
> >those useful features for me?
>
> And if I as the drivers developer _wish_ to use to be as portable as
> possible to other drivers, what forbids me to remove such a feature? :-)
>
> Sorry, but my argument was simply that I consider upwards portability in
> that point as less important.

Well, less important than what? ;)
It is not only 'upwards portability', but mostly 'convenience'
(possibility to use 'questionable features' with convenient
wrappers such as selectrow_hashref etc.).

So, CONVENIENCE vs WHAT?

> That's my view and you have a different. Fine
> for me. It is simply that my opinion counts as well as yours.

I think we can come to the compromise: this 'feature' can be made
optional and be default there will be a 'new' behavior.
But it should be an option to use an 'old' one.

> Volunteer for a patch? :-)

If I will make a patch for optional enabling end disabling
this 'feature' (the current behavior will be the default),
will you include this patch into the official version?

--

Regards, Walery Studennikov,
WebNames.Ru technical support

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, Jan 16, 2004 at 10:28:58AM +0100, Jochen Wiedmann wrote:
> Walery Studennikov wrote:
>
> >And what?
> >It is very convenient and practical for many developers.
> >If I _wish_ to use it for my convenience and if I don't want
> >to port my programs to other DBMS, why somebody forbids to use
> >those useful features for me?
>
> And if I as the drivers developer _wish_ to use to be as portable as
> possible to other drivers, what forbids me to remove such a feature? :-)
>
> Sorry, but my argument was simply that I consider upwards portability in
> that point as less important.

Well, less important than what? ;)
It is not only 'upwards portability', but mostly 'convenience'
(possibility to use 'questionable features' with convenient
wrappers such as selectrow_hashref etc.).

So, CONVENIENCE vs WHAT?

> That's my view and you have a different. Fine
> for me. It is simply that my opinion counts as well as yours.

I think we can come to the compromise: this 'feature' can be made
optional and be default there will be a 'new' behavior.
But it should be an option to use an 'old' one.

> Volunteer for a patch? :-)

If I will make a patch for optional enabling end disabling
this 'feature' (the current behavior will be the default),
will you include this patch into the official version?

--

Regards, Walery Studennikov,
WebNames.Ru technical support

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

Walery Studennikov wrote:

> Well, less important than what? ;)
> It is not only 'upwards portability', but mostly 'convenience'
> (possibility to use 'questionable features' with convenient
> wrappers such as selectrow_hashref etc.).
>
> So, CONVENIENCE vs WHAT?

Could you imagine that portability is a convenience as well? :-)


> If I will make a patch for optional enabling end disabling
> this 'feature' (the current behavior will be the default),
> will you include this patch into the official version?

I am not the maintainer. But I would of course vote for it.


Jochen


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

Walery Studennikov wrote:

> Well, less important than what? ;)
> It is not only 'upwards portability', but mostly 'convenience'
> (possibility to use 'questionable features' with convenient
> wrappers such as selectrow_hashref etc.).
>
> So, CONVENIENCE vs WHAT?

Could you imagine that portability is a convenience as well? :-)


> If I will make a patch for optional enabling end disabling
> this 'feature' (the current behavior will be the default),
> will you include this patch into the official version?

I am not the maintainer. But I would of course vote for it.


Jochen


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, 16 Jan 2004, Jochen Wiedmann wrote:

> Walery Studennikov wrote:
>
> > All queries with 'LIMIT ?,?' FAILS now,
> > because modern versions of MySQL fails to execute statements
> > with quoted LIMIT ranges.
>
> It should be noted, that almost definitely you cannot expect this to work
> with other drivers/databases as well. Likewise, you cannot expect that other
> drivers/databases are able to submit table/column names via placeholders.
>
> In particular, this will most likely *not* work with later version of
> *MySQL* that *are* supporting placeholders on the server side. (No doubt,
> we all want to use MySQL's server side placeholders if we can, do we?) In
> other words, I would consider these to be questionable features and do not
> see it as a reason to restore the old behaviour.
>

Mysql 4.1+ should make it easier to do the quoting stuff when using
server-side placeholders because I should be able to ask the server what
data type an individual placeholder is (and I am hoping for charset
to go with it).

Rudy


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, 16 Jan 2004, Jochen Wiedmann wrote:

> Walery Studennikov wrote:
>
> > All queries with 'LIMIT ?,?' FAILS now,
> > because modern versions of MySQL fails to execute statements
> > with quoted LIMIT ranges.
>
> It should be noted, that almost definitely you cannot expect this to work
> with other drivers/databases as well. Likewise, you cannot expect that other
> drivers/databases are able to submit table/column names via placeholders.
>
> In particular, this will most likely *not* work with later version of
> *MySQL* that *are* supporting placeholders on the server side. (No doubt,
> we all want to use MySQL's server side placeholders if we can, do we?) In
> other words, I would consider these to be questionable features and do not
> see it as a reason to restore the old behaviour.
>

Mysql 4.1+ should make it easier to do the quoting stuff when using
server-side placeholders because I should be able to ask the server what
data type an individual placeholder is (and I am hoping for charset
to go with it).

Rudy


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, 16 Jan 2004, Walery Studennikov wrote:

> On Fri, Jan 16, 2004 at 10:28:58AM +0100, Jochen Wiedmann wrote:
> > Walery Studennikov wrote:
> >
> > >And what?
> > >It is very convenient and practical for many developers.
> > >If I _wish_ to use it for my convenience and if I don't want
> > >to port my programs to other DBMS, why somebody forbids to use
> > >those useful features for me?
> >
> > And if I as the drivers developer _wish_ to use to be as portable as
> > possible to other drivers, what forbids me to remove such a feature? :-)
> >
> > Sorry, but my argument was simply that I consider upwards portability in
> > that point as less important.
>
> Well, less important than what? ;)
> It is not only 'upwards portability', but mostly 'convenience'
> (possibility to use 'questionable features' with convenient
> wrappers such as selectrow_hashref etc.).
>
> So, CONVENIENCE vs WHAT?

How about Security?

>
> > That's my view and you have a different. Fine
> > for me. It is simply that my opinion counts as well as yours.
>
> I think we can come to the compromise: this 'feature' can be made
> optional and be default there will be a 'new' behavior.
> But it should be an option to use an 'old' one.
>
> > Volunteer for a patch? :-)
>
> If I will make a patch for optional enabling end disabling
> this 'feature' (the current behavior will be the default),
> will you include this patch into the official version?

Yes. But so long as it does not allow sql injection attacks. Which can
be done, but is a pain because it will have to be done in C, and is not
trivial to get all possible cases where a number should not be quoted. But
if you are willing to tackle the problem, I will put the patch in.

DBD::mysql 3.0 with MySQL >= 4.1 Should be able to intorspect that
information when deciding on how to do quoting.

Rudy



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: LIMIT ?,? statement

On Fri, 16 Jan 2004, Walery Studennikov wrote:

> On Fri, Jan 16, 2004 at 10:28:58AM +0100, Jochen Wiedmann wrote:
> > Walery Studennikov wrote:
> >
> > >And what?
> > >It is very convenient and practical for many developers.
> > >If I _wish_ to use it for my convenience and if I don't want
> > >to port my programs to other DBMS, why somebody forbids to use
> > >those useful features for me?
> >
> > And if I as the drivers developer _wish_ to use to be as portable as
> > possible to other drivers, what forbids me to remove such a feature? :-)
> >
> > Sorry, but my argument was simply that I consider upwards portability in
> > that point as less important.
>
> Well, less important than what? ;)
> It is not only 'upwards portability', but mostly 'convenience'
> (possibility to use 'questionable features' with convenient
> wrappers such as selectrow_hashref etc.).
>
> So, CONVENIENCE vs WHAT?

How about Security?

>
> > That's my view and you have a different. Fine
> > for me. It is simply that my opinion counts as well as yours.
>
> I think we can come to the compromise: this 'feature' can be made
> optional and be default there will be a 'new' behavior.
> But it should be an option to use an 'old' one.
>
> > Volunteer for a patch? :-)
>
> If I will make a patch for optional enabling end disabling
> this 'feature' (the current behavior will be the default),
> will you include this patch into the official version?

Yes. But so long as it does not allow sql injection attacks. Which can
be done, but is a pain because it will have to be done in C, and is not
trivial to get all possible cases where a number should not be quoted. But
if you are willing to tackle the problem, I will put the patch in.

DBD::mysql 3.0 with MySQL >= 4.1 Should be able to intorspect that
information when deciding on how to do quoting.

Rudy



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org