Thread: Re: To Postgres Devs : Wouldn't changing the select limit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> If you're going to do that, *please* suggest the *correct* substitution.
>> AFAICT, our version of LIMIT m,n transposes to OFFSET m LIMIT n; but
>> your message suggests the opposite.
> Remember, the 7.1 code was:
> ! select_limit: LIMIT select_limit_value ',' select_offset_value
> ! { $$ = makeList2($4, $2); }
> This was changed a few weeks ago to match MySQL, and only today removed.
Wups, you're right, I was looking at the cvs-tip code not 7.1.
What was that about the order not being easy to remember? :-(
> However, our new message suggests the old PostgreSQL syntax, not the
> MySQL syntax. Optimally we should ship with this ordering for 7.2 and
> reverse it for 7.3 or 7.4.
Actually, it seems that the message should point out *both* the
old-Postgres and the MySQL translations. One camp or the other
is going to get burnt otherwise. Maybe:
ERROR: LIMIT #,# syntax no longer supported. Use LIMIT # OFFSET #.
If translating pre-7.2 Postgres: LIMIT m,n => LIMIT m OFFSET n
If translating MySQL: LIMIT m,n => OFFSET m LIMIT n
regards, tom lane
Tom Lane writes: > ERROR: LIMIT #,# syntax no longer supported. Use LIMIT # OFFSET #. > If translating pre-7.2 Postgres: LIMIT m,n => LIMIT m OFFSET n > If translating MySQL: LIMIT m,n => OFFSET m LIMIT n I think someone is panicking here for no reason, but I'm not sure who it is. If we think that LIMIT x,y should be phased out, then let's add that to the documentation and remove it in a later release, so people have a chance to prepare. But you're removing a perfectly fine feature that has received no attention in the last two years on the last day before beta because of a mysterious crowd of people porting from MySQL. Let me tell you: People porting from MySQL are going to have a lot of other problems before they find out that LIMIT works differently. In addition I want to repeat my object to notices and errors that are teaching syntax or trying to give smart tips. If a command is not syntactically correct then it's a syntax error. If the command used to be correct, might be correct in the future, or is correct in some other life then it's still a syntax error. If we want to have a "tip mode" then let's have one, but until that happens the documentation is the place to explain error messages or give advice how to avoid them. Now, of course this whole situation is a bit unfortunate because of the syntax mixup. But let's remember that most people that are going to use PostgreSQL 7.2 are the people that are using PostgreSQL 7.1 now, and they're going to be a lot happier the less they're going to be annoyed by gratuitous breaks in compatibility that had no prior notice at all. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> If you're going to do that, *please* suggest the *correct* substitution.
> >> AFAICT, our version of LIMIT m,n transposes to OFFSET m LIMIT n; but
> >> your message suggests the opposite.
>
> > Remember, the 7.1 code was:
>
> > ! select_limit: LIMIT select_limit_value ',' select_offset_value
> > ! { $$ = makeList2($4, $2); }
>
> > This was changed a few weeks ago to match MySQL, and only today removed.
>
> Wups, you're right, I was looking at the cvs-tip code not 7.1.
> What was that about the order not being easy to remember? :-(
Confusing syntax proven!
> > However, our new message suggests the old PostgreSQL syntax, not the
> > MySQL syntax. Optimally we should ship with this ordering for 7.2 and
> > reverse it for 7.3 or 7.4.
>
> Actually, it seems that the message should point out *both* the
> old-Postgres and the MySQL translations. One camp or the other
> is going to get burnt otherwise. Maybe:
>
> ERROR: LIMIT #,# syntax no longer supported. Use LIMIT # OFFSET #.
> If translating pre-7.2 Postgres: LIMIT m,n => LIMIT m OFFSET n
> If translating MySQL: LIMIT m,n => OFFSET m LIMIT n
I opted for a more generic message which makes clear the person it is
not a cut-and-past error message:
test=> select * from pg_class LIMIT 1,1;
ERROR: LIMIT #,# syntax no longer supported.
Use separate LIMIT and OFFSET clauses.
That should take care of it in a flexible way.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> Tom Lane writes:
>
> > ERROR: LIMIT #,# syntax no longer supported. Use LIMIT # OFFSET #.
> > If translating pre-7.2 Postgres: LIMIT m,n => LIMIT m OFFSET n
> > If translating MySQL: LIMIT m,n => OFFSET m LIMIT n
>
> I think someone is panicking here for no reason, but I'm not sure who it
> is. If we think that LIMIT x,y should be phased out, then let's add that
> to the documentation and remove it in a later release, so people have a
We took a vote on 'general' and had only one person who wanted it kept
for an additional release and several who wanted it removed right now.
> chance to prepare. But you're removing a perfectly fine feature that has
We are not removing the feature so much as forcing a syntax change on
user queries.
> received no attention in the last two years on the last day before beta
We have been _near_ beta for over one month now. It doesn't seem wise
to let this time just go to waste so I am trying to do what I can to
move PostgreSQL forward during this period.
The LIMIT #,# was actuall changed a almost a month ago in gram.y:
revision 2.253
date: 2001/09/23 03:39:01; author: momjian; state: Exp; lines: +3 -3
Implement TODO item:
* Change LIMIT val,val to offset,limit to match MySQL
This new activity is because someone asked about why the change was made
and the discussion on general led to this solution.
> because of a mysterious crowd of people porting from MySQL. Let me tell
> you: People porting from MySQL are going to have a lot of other problems
> before they find out that LIMIT works differently.
True.
> In addition I want to repeat my object to notices and errors that are
> teaching syntax or trying to give smart tips. If a command is not
> syntactically correct then it's a syntax error. If the command used to be
> correct, might be correct in the future, or is correct in some other life
> then it's still a syntax error. If we want to have a "tip mode" then
> let's have one, but until that happens the documentation is the place to
> explain error messages or give advice how to avoid them.
I disagree. If the 'tip' is localized to a few lines, usually in
gram.y, I don't see a reason not to help people find the right answer.
It helps them and reduces redundant bug repots. I can't imagine a
reason not to do it unless it starts to make our code more complex.
I don't want to jump through hoops to give people tips, but if it is
easy, let's do it.
> Now, of course this whole situation is a bit unfortunate because of the
> syntax mixup. But let's remember that most people that are going to use
> PostgreSQL 7.2 are the people that are using PostgreSQL 7.1 now, and
> they're going to be a lot happier the less they're going to be annoyed by
> gratuitous breaks in compatibility that had no prior notice at all.
Again, we took a vote on general. If there are people who want this
kept around for another release, we can do it. Let's hear from you.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026