Last modified: 2012-08-04 20:49:10 UTC
After removing the tsearch blocks in the installation (bug 12732) I discovered the following error when trying to view Special:Recentchanges:
A database error has occurred Query: SELECT * FROM recentchanges LEFT OUTER JOIN watchlist ON wl_user=1 AND wl_title=rc_title AND wl_namespace=rc_namespace WHERE rc_timestamp >= '2008-01-17 00:00:00 GMT' AND rc_bot = 0 ORDER BY rc_timestamp DESC LIMIT 50 OFFSET 0 Function: wfSpecialRecentchanges Error: 1 ERROR: operator does not exist: character = integer LINE 1: ...imestamp >= '2008-01-17 00:00:00 GMT' AND rc_bot = 0 ORDER ... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
#0 /home/wiki/includes/Database.php(799): DatabasePostgres->reportQueryError('ERROR: operato...', 1, 'SELECT * FROM r...', 'wfSpecialRecent...', false)
#1 /home/wiki/includes/SpecialRecentchanges.php(167): Database->query('SELECT * FROM r...', 'wfSpecialRecent...')
#2 [internal function]: wfSpecialRecentchanges(NULL, Object(IncludableSpecialPage))
#3 /home/wiki/includes/SpecialPage.php(677): call_user_func('wfSpecialRecent...', NULL, Object(IncludableSpecialPage))
#4 /home/wiki/includes/SpecialPage.php(463): SpecialPage->execute(NULL)
#5 /home/wiki/includes/Wiki.php(193): SpecialPage::executePath(Object(Title))
#6 /home/wiki/includes/Wiki.php(45): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#7 /home/wiki/index.php(89): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
This is due to the fact that implicit casts were removed in 8.3 as "text = int" is a Bad Thing (tm)
Since I just managed to get SVN version running on PG 8.3 this is the only place I've seen this error, but since I'm sure rc_timestamp is used in a lot more places then this one page this really is a non-trivial error.
PostgreSQL 8.3 has been released.
As such, mediawiki now fails to install, much less run on a released version of PG.
Well I stand corrected, the problem didn't lie with rc_timestamp but rc_bot. It's due to the fact that the tables are defined as character(1), but then you use an integer in the SQL.
Other possible sources of problems are the following fields which are also character(1):
Again the solution is either use an actual integer field (tinyint is 2bytes) instead of character(1) (1 bytes + content) or have do to lots of coding to add casts on all potential queries that use these fields.
Postgres does not have a tinyint, but I did change them all to smallint (r30800), which is the only solution for now. Unfortunately, MySQL does not have a true boolean type, and the code does a lot of 0/1 manipulation instead of true/false.