Looks like it is a regression in the way we pass page_id to some new user hook.

Added to 1.19 tracking per bugmeister's email.

Can we check how much regression is this?

PostgreSQL allows NULL in cuc_page_id but does not allow 0 because of constraint.

MySQL the reverse - allows 0 but it's NOT NULL.

We even explicitly insert zero in the new extension code, but I am not sure what's coming via hooks. We are also using some other hooks (e.g. bug 19963
fixed with r88258 as well as some new hooks), so probably it's best to detect zero and covert it to NULL.

I would tend to change cuc_page_id to NULL on MySQL (yeah, on this means on Wikimedia too) plus fix the code where necessary.

Is this okay with everyone?

Asher - could you possibly to comment on this schema change?12

afeldman wrote:

I think having cuc_page_id default to NULL makes more sense, and enwiki currently has slightly over 1 million rows in cu_changes where cuc_page_id = 0, out of ~16mil rows total.

That said, it is only until relatively recently (in the history of mysql) that NULL values have been allowed for integer types.

http://bugs.mysql.com/bug.php?id=44243

That's why you'll see DEFAULT NULL in the char fields, but NOT NULL DEFAULT 0 for the ints.

Changing this is ok wrt the version of mysql in production at wmf, but would require increasing the minimum required version of mediawiki beyond what it currently is.

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