Fixed in r32226, thanks for the report.

overlordq wrote:

"rc_old_len='$lastSize',rc_new_len=$size "

quotes around $lastSize will still throw the error as shown the SQL in comment 0, call it line 93 of same file if the page is new.

overlordq wrote:

Working now :)

overlordq wrote:

This seems to have regressed to being broken again.

I'll attach the output

overlordq wrote:

Backtract + output

Attached:

overlordq wrote:

Seems to be r49112 that causes this.

'rc_cur_id' => 'COALESCE(page_id, 0)'

was there a problem with that field being NULL vs 0?

(In reply to comment #6)

Seems to be r49112 that causes this.

'rc_cur_id' => 'COALESCE(page_id, 0)'

was there a problem with that field being NULL vs 0?

Has to be I guess, but it seems weird to me because we use 0 in this role in a lot of other places as well (e.g. rev_user, which is either a valid user_id or 0). Is there even any benefit from adding these relations between tables in the postgres schema? The MySQL schema doesn't have them.

overlordq wrote:

The benefit is getting warnings like this that your software is trying to insert data that doesn't make sense. Without strict mode MySQL is known to do some really silly things when inserting data and foreign keys would catch that.

The hackish way would be to create a stub page like is done for anonymous users and user_id 0 but that would likely do odd things elsewhere.

I guess without doing something strange like splitting up the log table into actions against pages and actions against users, would be to drop the constraint.

(In reply to comment #8)

The benefit is getting warnings like this that your software is trying to
insert data that doesn't make sense.

That's not true. rc_cur_id=0 DOES make sense, it has a well-defined meaning. PostgreSQL should not try to enforce its conception of what makes sense over MW's. For that reason, the constraint should be dropped IMO, as you suggest.

overlordq wrote:

Fixed in r58269

Migrating from the old tracking task to a tag for PostgreSQL-related tasks.