MySQL Bugs: #6298: LIMIT #, -1 no longer works to set start with no end limit

Bug #6298	LIMIT #, -1 no longer works to set start with no end limit
Submitted:	28 Oct 2004 9:13	Modified:	24 Jan 2007 22:10
Reporter:	[ name withheld ]	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Tests	Severity:	S7 (Test Cases)
Version:	4.1	OS:	Any (Any)
Assigned to:	Marc ALFF	CPU Architecture:	Any
Tags:	limit, rt_q1_2007

Description:
There is a bug in Russian docs concerning "LIMIT" option. It says that one can retrieve records up to the end using "-1" for the second LIMIT parameter (old style) which is wrong now because one should use some "large number" instead.

PS. I was rather disappointed with that change in MySQL behaviour, can't see any reason why they did that.

How to repeat:
Just use your existing SQL code for versions <4.1 with SELECT ... LIMIT n,-1

Suggested fix:
I would suggest it to be reverted to the old behaviour (dream on). At least correct the docs, please.

Antony, this is caused by the same parser change that rendered "DEFAULT -1" illegal
(that you fixed). Could you try to fix the LIMIT too ?

Updating the synopsis to be more descriptive.

This is a parser bug, stealing.

Maxim, could you come up with a use case when this can be useful?
This feature was present in 4.0 and 3.23 but is not documented.
We do not support undocumenting features, but I am just curious to see value of this.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/17590

ChangeSet@1.2321, 2007-01-03 11:47:01-07:00, malff@weblab.(none) +2 -0
  Bug#6298 (LIMIT #, -1 no longer works to set start with no end limit)
  
  With MySQL 3.23 and 4.0, the syntax 'LIMIT N, -1' is accepted, and returns
  all the rows located after row N. This behavior, however, is not the
  intended result, and defeats the purpose of LIMIT, which is to constrain
  the size of a result set.
  
  With MySQL 4.1 and later, this construct is correctly detected as a syntax
  error.
  
  This fix does not change the production code, and only adds a new test case
  to improve test coverage in this area, to enforce in the test suite the
  intended behavior.

The Russian manual is for MySQL 4.0, for which -1 does
actually work.  But we no longer update this manual because
MySQL 4.0 has been end-of-lifed.  For the current behavior,
please see the current English-language manual. Thanks.