"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote: 
>> Or is someone prepared to argue that there are no applications out
>> there that will be broken if the same query, against the same unchanging
>> table, yields different results from one trial to the next?
 
> If geqo kicks in, we're already there, aren't we?

Yup, and that's one of the reasons we have a way to turn geqo off.
(geqo is actually a good precedent for this --- notice that it has
an on/off switch that's separate from its tuning knobs.)

> Isn't an application which counts on the order of result rows
> without specifying ORDER BY fundamentally broken?

No doubt, but if it's always worked before, people are going to be
unhappy anyway.

Also, it's not just ordering that's at stake.  Try

regression=# create table foo as select x from generate_series(1,1000000) x;
SELECT
regression=# select * from foo limit 10000;
   x   
-------
     1
     2
     3
     4
 ....
regression=# select * from foo limit 10000;
   x   
-------
  7233
  7234
  7235
  7236
  ....
regression=# select * from foo limit 10000;
   x   
-------
 14465
 14466
 14467
 14468
 ....

Now admittedly we've never promised LIMIT without ORDER BY to be
well-defined either, but not everybody reads the fine print.
This case is particularly nasty because at smaller LIMIT values
the result *is* consistent, so you might never notice the problem
while testing.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to