@i @fwc @phnt

> user/version agents seem like a valid thing to intern to a table join,

Sure. They're treated as an opaque string and that wouldn't be hard to do as a join and I think the amount of time spent pulling it (the historical table doesn't even expose that data), but like I said, it's not a disk space or index size issue, it's the size of the page, and there has to be *some* limit: it is dirty data from the web.

So what's a good limit? Like, it costs potentially a meg now; 64 characters would be two megs on that page. 32 seems reasonable to me: it's enough space for "10.9.9.9.9.9.9.9.9.9.9.9+0123456". I don't think it'd be useful to add more than that.

> expected a varchar with validation on the client side so the change is a *2 and not a migration

By habit, I usually have the DB enforce as much as I can, but it looks like I didn't in this case. Like I said in the second correction, the migration wouldn't be a big deal; it looks like it would be an even smaller deal than expected because it wouldn't exist. The only constraints on instance_log are "NOT NULL" on id, instance_id, and ctime.