On Fri, Feb 14, 2003 at 01:04:00PM -0500, Luc Foisy wrote: > I didn't say it had nothing to do with the data, I said it had > nothing to do with the data in the database. The data in the > recordset returned from the database referenced by row is important.
[...] > 1. There are a lot of functions that return values that have nothing > to do with data contained in the database. Math functions for one, > they calculate return values using data that is in the database. And > many many other functions. Why not one more. You're not just asking for a function whose input doesn't come from the database, you're asking for one whose input comes from a later pass in data processing. After the row is inserted into the final result set, this value has to be updated. > In the 4.x series the > developers implemented SQL_CALC_FOUND_ROWS and FOUND_ROWS(), > something that could just have easily been handled by external > programming... I'm sure they weighed the utility of the change (saves a lot of traffic and time, when you need it) against the complexity of its implementation (probably very little, given what it does) and decided it was worth it. Every addition to a language or library has to be made very carefully because they generally will be there forever. The function you describe requires a row to be updated where currently there is no updating going on, adding complexity where there is none now. > 2. There is a use for it. since... > > 3. Going through the archives, I have seen many many people ask for >it. I've seen people ask for a ROWNUM() function or somesuch, which reveals the implementation's ordering of records in the source table; that request shows up once in a while (and usually reveals a misunderstanding of rdbms, imo). But in the result set? We're talking about $resultNum++ as you loop through the results. (Or the @x solutions other people have mentioned.) I've never heard someone ask for the functionality you want before. Even if there were many such requests, assigning serial numbers to sequential output, if that's what you want, is what general purpose languages are for, not what relational databases are for. Imo. Extreme example: Why not add "SELECT ... INTO EMAIL [EMAIL PROTECTED]" to the language so the server can email you results? (You may find examples where the folks at MySQL have chosen to add non-rdbms features into their server, but that doesn't mean they want to add anything whatsoever and then maintain it forever.) > 4. Those numbers probably already exist, how else does it ORDER BY, > it has to put the results in an array of some kind I believe those numbers are unknown when generating the row values. -- Pete Harlan, who doesn't speak for the MySQL developers of course. [EMAIL PROTECTED] --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
