[03:44:19] <milimetric>	 tgr: I agree it's unwise... but this approach to code really bothers me.  As I said, it's a one time thing, and 1. it works perfectly fine right now (which is the only time I'll run it) and 2. it is one line as opposed to a few functions required to parse the ridiculously over-complicated structure of the sitematrix.
[03:44:53] <milimetric>	 so, on my prioritized list of unwise things, it's waay below "crappy sitematrix structure" and "omg logging table is an insane historical mess"
[03:45:53] <milimetric>	 the logging table being a mess is the whole reason I'm having to build this namespace mapping in the first place, because log_params, even after 4 different historical changes, still doesn't include the target page's namespace...
[03:46:22] <milimetric>	 not to mention log_params is php serialized... which ... speaking of unwise, right?
[03:47:12] <milimetric>	 so yeah, my one line hack to do a one-time thing... not really worth all the fuss, I think, but us finally cleaning up page move history and reconstructing it from the logging table did seem like it was worth at least a \o/ or hooray or something.
[03:47:17] <milimetric>	 tough crowd...
[17:13:29] <Krenair>	 milimetric, shouldn't log_namespace have the target namespace?
[19:07:10] <milimetric>	 Krenair: no, sadly that's the ns of the source page.  In most cases it's the same, but it can of course be different.  And in some cases it's null, so the data's cleaner if we parse it out of the target page title.
[19:08:41] <milimetric>	 I noticed log_page changed from the source to the target page id in Sept, 2014, but was surprised the log_namespace didn't change with it.  I read the code of MovePage and ManualLogEntry, it seemed to agree