On Mon, Sep 27, 2010 at 2:55 PM, Ilmari Karonen <nospam(a)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).