[Phpmyadmin-devel] about explicit LIMIT

[cand. inf. Alexander M. Turek]

Hi Sebastian & list,

Sebastian Mendel schrieb:
>
> having a query like:
>
> SELECT * FROM `tab` ORDER BY `a` LIMIT 3
>
> with more than 3 rows in `tab`
>
> will result in 3 completely different rows when clicking on column `b`
> in the result table
>
> is this what the user expects?

Probably not, but semi-smart auto-pagination won't help either. For
MySQL >= 4.1 we can fix that by surrounding the users original query
with a SELECT that adds the clauses we need for pagination and
reordering and this is probably the way to go for at least PMA 3.0.
Without subselects, I don't see a way to fix that, right now.

Of course, the whole discussion appears ridiculous when thinking about
limiting a query to 3 or 5 result rows. But when talking about
databases, we have to think about the ones that have a couple of more
records and about queries that return a couple of more rows. Limiting a
query to 500 or 1000 rows is ihmo not a stupid thing to do. :-)

The intention of LIMIT is not pagination but a kind of selection. This
is why I would not expect an appended LIMIT to affect phpMyAdmin's
pagination behavior. phpMyAdmin just uses LIMIT for pagination, but it's
rather a hack, since we do not have something like server-side results
with pointers that we can keep alive during multiple requests of a
session. We should respect the purpose of the keyword, imho.

On the other hand, buttons to remove certain parts of the outermost
query (like LIMIT, ORDER BY) - as long as the interface does not get too
bloated - would be fine for me. What do you think?

Regards,

Alexander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20071217/3753d94a/attachment.sig>