On Mon, Sep 27, 2010 at 2:55 PM, Ilmari Karonen nospam@vyznev.net wrote:
Why do we even include those rows in the default views? I don't think most people expect to get deleted rows on a simple query on the revision table, given that this was never the case under the old system (when they were moved to the archive table instead).
If someone really needs those rows, I guess we could always set up alternative views that include then. But I'd think that would be rather uncommon use case. (How many TS users are actually doing something with the archive table, anyway?)
We already have two alternative views for the logging table, so this is doable. If we add copies of all indexes prefixed with rev_deleted, everything should be just as efficient in a view as you suggest, so I don't see why we couldn't. In other cases there have been issues with efficiency, but I don't see why those should exist here, offhand.
(Compare with e.g. the absence of the user_password field from the views. Technically, there shouldn't be much risk in exposing it, since it's salted and hashed, but there's little if any valid need for it either.)
There'd be tremendous risk in publishing salted and hashed passwords. You can run an automated password cracker on those and try thousands of passwords per second or more, even millions per second. You'd be able to quickly recover the password of anyone who used a dictionary word or other common password if you had access to the hashes. You can't do this online, because there's throttling -- and even just the overhead of an HTTP request makes it hard to do thousands of attempts per second (let alone millions).