Last modified: 2012-08-04 20:48:46 UTC
If you click show/hide on a revision to hide it you get a database error: === A database error has occurred Query: SELECT log_type,log_action,log_user,log_namespace,log_title,log_params,log_comment,log_id,log_deleted,log_timestamp,user_name,user_editcount,ts_tags FROM logging INNER JOIN mwuser ON ((user_id=log_user)) INNER JOIN log_search ON ((ls_log_id=log_id)) LEFT JOIN tag_summary ON ((ts_log_id=log_id)) WHERE log_type = 'delete' AND log_action = 'revision' AND ls_field = 'rev_id' AND ls_value = '1532' AND (log_type != 'suppress') AND log_namespace = '0' AND log_title = 'Main_Page' AND ((log_deleted & 9) != 9) AND (user_id = log_user) GROUP BY ls_log_id ORDER BY log_timestamp DESC LIMIT 26 Function: IndexPager::reallyDoQuery (LogPager) Error: 1 ERROR: column "logging.log_type" must appear in the GROUP BY clause or be used in an aggregate function === Is there a reason behind the group-by on that field?
Yes, it is needed...though maybe a different way of expressing it would help PG
I'm just wondering why it specifies a group by ls_log_id on the log_search table since as far as I can tell a new log id is generated for every action so a group by on that column is both pointless and bad SQL
One log can change several items. If I delete 3 items at once and then view the logs for those three items I'd expect to see that one log entry once rather than three times.
Then why not use DISTINCT instead of group by? Although we know the rows are the same, the DB doesn't know that, so saying group by ls_log_id it goes "Well which log_type should I return you?" instead of MySQL's "Here's a random log_type".
Committed as r59692, tested and seems to work fine with PG now.
