Thread: Re: [GENERAL] To Postgres Devs : Wouldn't changing the
...
> Are you subscribed to general?
...
> Everyone thought LIMIT # OFFSET # was preferred.
I think Hiroshi's point is the same as mine: discussions of feature
changes need to happen on -hackers before being implemented.
Subscriptions to other mailing lists should not be required to stay up
with mainstream development issues.
I'm recently subscribed to -general, to allow me to respond to email
threads, but it has a lot of traffic and I may not stay subscribed for
long...
- Thomas
OK, then why did Tom tell me to have the discusion on general? Don't we ask the general users about user-visible feature removal? The is not an implementation issue but a simple, "What do users want?" I agree it would be good on hacker too, but how do we have a discussion on both? > ... > > Are you subscribed to general? > ... > > Everyone thought LIMIT # OFFSET # was preferred. > > I think Hiroshi's point is the same as mine: discussions of feature > changes need to happen on -hackers before being implemented. > Subscriptions to other mailing lists should not be required to stay up > with mainstream development issues. > > I'm recently subscribed to -general, to allow me to respond to email > threads, but it has a lot of traffic and I may not stay subscribed for > long... > > - Thomas > -- 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, Pennsylvania19026
Thomas Lockhart <lockhart@fourpalms.org> writes:
> I think Hiroshi's point is the same as mine: discussions of feature
> changes need to happen on -hackers before being implemented.
Well, IIRC there *was* some discussion about this some months back, and
no one particularly objected to changing it to be compatible with MySQL.
That's why Bruce felt free to execute on the TODO item despite being
so close to beta.
> Subscriptions to other mailing lists should not be required to stay up
> with mainstream development issues.
Actually, the reason we have an argument now is the other way around:
some non-hackers people complained when the change notice went by.
We do have an obligation to users who don't read -hackers.
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.
regards, tom lane
Lamar Owen <lamar.owen@wgcr.org> writes:
> The behavior currently is rather broken according to the results of the
> discussion on general. Do we really want a whole 'nother major version cycle
> to pass before this kludge is fixed? Six months to a year down the road?
> The longer this behavior is in the code, the harder it's going to be to
> remove it, IMNSHO.
I agree completely with these points, which is why I'd rather have seen
it dealt with (one way or t'other) in 7.2. But we appear to have a lot
of people who don't think it's been discussed adequately in
$PREFERRED_FORUM ... and the one thing I *really* don't want is to hold
up 7.2 beta anymore for this issue. Let's stuff this worm back in the
can and get on with it.
regards, tom lane
On Monday 22 October 2001 10:32 pm, Tom Lane wrote: > Thomas Lockhart <lockhart@fourpalms.org> writes: > > I think Hiroshi's point is the same as mine: discussions of feature > > changes need to happen on -hackers before being implemented. [snip] > > Subscriptions to other mailing lists should not be required to stay up > > with mainstream development issues. > Actually, the reason we have an argument now is the other way around: > some non-hackers people complained when the change notice went by. > We do have an obligation to users who don't read -hackers. If they want to deal with development issues, let them subscribe to hackers. Sorry, I know that's more than a little rude. But that _is_ what the hackers list is for, right? 'The developers live there' is the advertisement..... As I'm subscribed to most of the postgresql lists, I sometimes miss which list it's on -- but I'll have to say that I agree with both Thomas and Bruce: the behavior needs to be fixed, AND it needs to be discussed on hackers before fixing. > 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. Communications breakdown either way. The warning and discussion was on general -- a bcc to hackers would have been a good thing, IMHO. But that's past. It's mighty close to beta -- is this fix a showstopper? The behavior currently is rather broken according to the results of the discussion on general. Do we really want a whole 'nother major version cycle to pass before this kludge is fixed? Six months to a year down the road? The longer this behavior is in the code, the harder it's going to be to remove it, IMNSHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> Thomas Lockhart <lockhart@fourpalms.org> writes: > > I think Hiroshi's point is the same as mine: discussions of feature > > changes need to happen on -hackers before being implemented. > > Well, IIRC there *was* some discussion about this some months back, and > no one particularly objected to changing it to be compatible with MySQL. > That's why Bruce felt free to execute on the TODO item despite being > so close to beta. > > > Subscriptions to other mailing lists should not be required to stay up > > with mainstream development issues. > > Actually, the reason we have an argument now is the other way around: > some non-hackers people complained when the change notice went by. > We do have an obligation to users who don't read -hackers. > > 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. [ BCC to general ] I agree. Let me reverse this to 7.1 behavior, and note in the HISTORY file that LIMIT #,# will be removed in 7.3. That way, people know it is coming and it gives them one release to fix their queries. I know Tom wanted it removed right away because it is so confusing but I think we have enough votes to keep it around, unchanged, for another release. As to whether we should emit a NOTICE every time LIMIT #,# is used, I think not, but if people want it I can add it. -- 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
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. >
> But that's past. It's mighty close to beta -- is this fix a showstopper? > The behavior currently is rather broken according to the results of the > discussion on general. Do we really want a whole 'nother major version cycle > to pass before this kludge is fixed? Six months to a year down the road? > > The longer this behavior is in the code, the harder it's going to be to > remove it, IMNSHO. We just have too many opinions here. I have put it back and noted it will be removed in 7.3. If someone else wants to propose it to be removed in 7.2 and have a vote, and do the work, and take the heat, go ahead. I am not going to do it. It is just like the grief I got over jdbc patches for 7.1. At some point it is not worth having people get upset at me over it. Basically, you have removed any desire I have to resolve this. FYI, my personal opinion is that we should keep it around for one more release because forcing people to remove it from the queries with no warning is more disruptive, I think, than the fact we don't match MySQL's syntax. Also, LIMIT #,# is no longer documented. That change will be in 7.2. Of course, that means that if someone tries MySQL's syntax, they have no documentation stating that the params are backwards. If they read the HISTORY file, they will know not to use LIMIT #,# anyway. -- 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, Pennsylvania19026
> I agree completely with these points, which is why I'd rather have seen
> it dealt with (one way or t'other) in 7.2. But we appear to have a lot
> of people who don't think it's been discussed adequately in
> $PREFERRED_FORUM ... and the one thing I *really* don't want is to hold
> up 7.2 beta anymore for this issue. Let's stuff this worm back in the
> can and get on with it.
Frankly, I'd be happy to consider this a bug fix either way. The timing
is compatible with 7.2, and I'm happy that Bruce is bringing this to
resolution. My point was simply that some discussion on -hackers is
appropriate, and that others on -hackers who might have a stake in this
should be in on the discussion.
fwiw, I don't have a strong opinion about *which* path is taken to fix
the problem. But the old implementation is the worst of all worlds, and
the replacement syntax which is already in the code is a better choice.
- Thomas
> Not possible to accept both forms at present and issue a notice that > LIMIT m,n is deprecated? We accept both now and will for <=7.2. In 7.3, it will be only LIMIT # OFFSET #. -- 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, Pennsylvania19026