Re: [GENERAL] To Postgres Devs : Wouldn't changing the selectlimit - Mailing list pgsql-hackers

From David Ford
Subject Re: [GENERAL] To Postgres Devs : Wouldn't changing the selectlimit
Date
Msg-id 3BD4FB0B.6010205@blue-labs.org
Whole thread Raw
In response to Re: [GENERAL] To Postgres Devs : Wouldn't changing the  (Thomas Lockhart <lockhart@fourpalms.org>)
Responses Re: [GENERAL] To Postgres Devs : Wouldn't changing the selectlimit
List pgsql-hackers
Not possible to accept both forms at present and issue a notice that 
LIMIT m,n is deprecated?

If LIMIT m,n is found, internally re-write it to LIMIT m OFFSET n and 
press on.

This should appease everyone and still allow the 'proper' form to be 
implemented right now.  There isn't just the question of when it appears 
in pgsql, but when it appears in everyone else's code that depends on 
postgres.  If you delay LIMIT..OFFSET, then I too am affected in my 
code.  If I use it today and my code is in beta (which it is), then when 
it goes release, I'll have to issue a change in the future for that. Granted it's not a big thing for me, but if I have
200,000
 
installations, that means eventually there will have to be 200,000 
upgrades when they upgrade postgres.

We all know that everyone updates their software frequently and in a 
timely manner to keep things running smoothly, right?  *cough*

David

Tom Lane wrote:

>Given the amount of noise being raised on the issue now, I think the
>better part of valor is to revert to the 7.1 behavior and plan to
>discuss it again for 7.3.  But it's not like Bruce did this with no
>warning or discussion.
>




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] To Postgres Devs : Wouldn't changing the selectlimit
Next
From: Doug McNaught
Date:
Subject: Re: Index of a table is not used (in any case)