in reply to Re: SQL::Statement limit clause with placeholders
in thread SQL::Statement limit clause with placeholders

Actually, the LIMIT clause is applied before the data are retrieved, as it can influence the execution plan. Something with a LIMIT above the number of records in the table shouldn't use indexes, whereas something with a LIMIT of 1 should. See 7.2.12. How MySQL Optimizes LIMIT.

My normal rule of thumb is that placeholders work on values (field values, or values derived from them in the case of some where clauses), not parameters (limit clause, 'DESC' in the case of ordering), names (field names, table names, schema names, etc). Unfortunately, the mysql documentation doesn't seem to cover what it's allowed to replace. (There's a section in the documentation 13.7. SQL Syntax for Prepared Statements, and the closest I can find is the explaination of the various data types for placeholders in 24.2.5. C API Prepared Statement Data types)

  • Comment on Re^2: SQL::Statement limit clause with placeholders

Replies are listed 'Best First'.
Re^3: SQL::Statement limit clause with placeholders
by dragonchild (Archbishop) on Jun 03, 2005 at 14:59 UTC
    DBD::mysql allows placeholders in the LIMIT clause. It's not clear whether MySQL itself is as accomodating.

    The difference arises because DBD::mysql handles placeholders client-side. There is a push to have the DBD hand off placeholders to the server (now that MySQL supports server-side prepares), but the current CPAN version doesn't have that functionality yet. q.v. New twist for DBD::mysql for more on the topic.


    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
Re^3: SQL::Statement limit clause with placeholders
by jZed (Prior) on Jun 03, 2005 at 15:01 UTC
    In SQL::Statement there are two kinds of LIMIT clauses -those that can be applied during a search and those that can only be applied afterwards. Strictly speaking, a LIMIT clause without an ORDER BY clause makes no sense since it depends on the physical ordering of rows (which nothing ever should). But given the way S::S operates, I allow it to do LIMIT without ORDER BY since that's the only way to actually limit what is being searched as distinct from limiting a result set after a search.

      Although it's not typical, there are times when I find the use of a limit, without the use of ORDER BY to be very useful--

      If you're attempting to get the field that will be returned by a query (typically because of stuff like 'SELECT * FROM table'), adding a limit is useful, but you can also just throw in 'WHERE 0=1'.

      If you're attempting to clear a queue of some sort, where it doesn't need to be FIFO or otherwise processed in some particular order, but you can't have it run for too long. (so you can work in 500 record sets, rather than working on the whole queue at once) I found this very useful in Oracle, when I'd have to limit my processing time for each transaction so I didn't exceed my rollback segments as the system tried to maintain transactional consistency. (and unfortunately, due to the nature of the problem, I couldn't just set the transaction SERIALIZABLE ... I might've been able to use a autonomous transaction, though)

      So, in most situations, I agree that it doesn't make sense, but there are times when it does, and it probably has more to do with how the programmer thinks about the problem more than anything else -- there are other working solutions for the examples that I've given above, but using limits without ordering in those situations makes sense to me.