> Bruce Momjian writes:
>
> > I recommend tips when they are one line in length, have a high
> > probability of being accurate, and are common mistakes. Anything longer
> > and we should point to a specific section in the docs.
>
> I would put "when porting from MySQL" into that category.
I wo
Bruce Momjian writes:
> I recommend tips when they are one line in length, have a high
> probability of being accurate, and are common mistakes. Anything longer
> and we should point to a specific section in the docs.
I would put "when porting from MySQL" into that category.
--
Peter Eisentra
Bruce Momjian writes:
> It was on the TODO list, and I did exactly what was listed there. What
> we have now is a discussion that the TODO item was wrong.
I don't consider the items on the TODO list to be past the "adequately
discussed" stage.
To the topic at hand: I find reversing the argume
> Bruce Momjian writes:
>
> > It was on the TODO list, and I did exactly what was listed there. What
> > we have now is a discussion that the TODO item was wrong.
>
> I don't consider the items on the TODO list to be past the "adequately
> discussed" stage.
>
> To the topic at hand: I find re
> 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
[EMAIL PROTECTED] | (610) 85
> 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
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 quest
> 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 dow
> Thomas Lockhart <[EMAIL PROTECTED]> 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 chan
On Monday 22 October 2001 10:32 pm, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> 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 r
Lamar Owen <[EMAIL PROTECTED]> 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 i
Bruce Momjian wrote:
>
> > > I don't think that enough votes are needed to reverse
> > > the change. You broke the discussion first rule.
>
> Are you subscribed to general? We had a big discussion there and there
I know the discussion and I've thought Peter's objection was
suffienctly valid to
> Bruce Momjian wrote:
> >
>
> [snip]
>
> >
> > What do others think?
>
> Please reverse your change and go into beta quickly.
I need more information. What do you want reversed, and are there
enough votes to reverse those votes already made?
--
Bruce Momjian|
Thomas Lockhart <[EMAIL PROTECTED]> 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 b
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?
> ...
> > A
> > I don't think that enough votes are needed to reverse
> > the change. You broke the discussion first rule.
Are you subscribed to general? We had a big discussion there and there
was almost universal agreement that the LIMIT #,# syntax is too
error-prone, and the only reason to have it was f
...
> 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
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > >
> >
> > [snip]
> >
> > >
> > > What do others think?
> >
> > Please reverse your change and go into beta quickly.
>
> I need more information. What do you want reversed,
revision 2.253
date: 2001/09/23 03:39:01; author: momjian; state: Exp
Bruce Momjian wrote:
>
[snip]
>
> What do others think?
Please reverse your change and go into beta quickly.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Bruce Momjian wrote:
>
> > (switched thread to hackers)
> >
> > > ... 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 i
> > I need more information. What do you want reversed,
>
> 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
>
> and the related description in HISTO
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I'm with Peter on this one. I'd like to *not* clutter up the code and
> error reporting with hints and suggestions which may or may not be to
> the point.
> We *should* have docs which list error messages and possible solutions,
> and throwing that inf
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > I'm with Peter on this one. I'd like to *not* clutter up the code and
> > error reporting with hints and suggestions which may or may not be to
> > the point.
> > We *should* have docs which list error messages and possible solutions,
> > and throw
(switched thread to hackers)
> ... 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 comple
> (switched thread to hackers)
>
> > ... 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
> > > > I am confused. While LIMIT and OFFSET may are potential SQL standard
> > > > reserved words, I don't see how LIMIT #,# would ever be a standard
> > > > specification. Do you see this somewhere I am missing. Again, LIMIT
> > > > #,# is the only syntax we are removing.
> > > If you are co
> > > I am confused. While LIMIT and OFFSET may are potential SQL standard
> > > reserved words, I don't see how LIMIT #,# would ever be a standard
> > > specification. Do you see this somewhere I am missing. Again, LIMIT
> > > #,# is the only syntax we are removing.
> > If you are confident th
27 matches
Mail list logo
