There is some bad SQL that runs after the upgrade code in checksetup, that prevents a normal checksetup run from finishing on PostgreSQL. Once this bug is RESOLVED, checksetup will be able to run correctly on PostgreSQL for the creation of a brand-new database.

We were relying on a lot of bad MySQL-specific behavior here. Notably, that MySQL allows you to exclude NOT NULL fields from the INSERT statements (which sort of defeats the entire purpose of NOT NULL...).

Comment on attachment 176842 [details] [diff] [review] Make checksetup complete properly on PostgreSQL >- (name, description, userregexp, isbuggroup) >- VALUES (?, ?, ?, ?)'); >+ (name, description, userregexp, isbuggroup, >+ last_changed) >+ VALUES (?, ?, ?, ?, NOW())'); this is fine, however the rest of the patch (converting to sql placeholders) really belongs on another bug.

Comment on attachment 176842 [details] [diff] [review] Make checksetup complete properly on PostgreSQL behold the speed of my flip-flop. i missed these changes :( >- "INSERT " . >- " INTO profiles (login_name, realname, cryptpassword, emailflags) " . >- "VALUES ($login, $realname, $cryptedpassword, $defaultflagstring)"); >+ q{INSERT INTO profiles (login_name, realname, cryptpassword, >+ emailflags, disabledtext, refreshed_when) >+ VALUES (?, ?, ?, ?, ?, ?)}, >+ undef, $login, $realname, $cryptedpassword, >+ Bugzilla::Constants::DEFAULT_EMAIL_SETTINGS, '', '1900-01-01 00:00:00'); anyhow, >+ my $group_exists = $dbh->selectrow_array( >+ q{SELECT 1 FROM group_group_map >+ WHERE member_id = ? AND grantor_id = ? AND grant_type = ?}, >+ undef, $whineatothers_group, $whine_group, GROUP_MEMBERSHIP); >+ $dbh->do("INSERT INTO group_group_map " . nits: not a fan of q{} where quotes will do. can you use SELECT COUNT instead?

Checked-in as-is. :-) (It's late. :-)) Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.364; previous revision: 1.363 done