A downside to NAT for a small home network? How about when you have two or more servers both listening on port 22, and externally you have to remember which port you plucked from thin air in order to be able to get to it? This of course being multiplied by the number of servers and number of services being run on them. It's not the end of the world (for a small network) but it offers no benefit except for conserving IPs.
*(Yes, yes, yes, I'm well aware I've just described one-to-one NAT, but I think it's pretty clear that that's not the type of NAT I'm arguing against.)
NAT solves ONE problem: more devices than public IPs. Any perceived security benefits are purely incidental and can be solved (better) by a firewall.
But I reiterate: PHP probably isn't the language for you. I understand your position, as I'm completely anal about code being free from all warnings too. However; I'm also of the opinion that strict type checking actually provides comparatively little benefit. When I fix bugs in our codebase it's almost never due to type mismatches, in fact I can only think of two instances ever where I've thought strong typing would have prevented a bug. On the one hand you may claim that's two bugs too many, but on the other hand that's several years of IMO faster development gained by not having to jump through hoops.
I've yet to use a language with a full type inference system, but it seems like that may be a pretty awesome compromise.
If you want to compare rows, don't bother with a slow and clumsy self-join, use a windowing function and the lead/lag functions. e.g. to list the interesting events and time between them:
select date, message, lead(date) over (order by date) - date as time_to_next from log where type='interesting';
That only shows 'interesting' events, of course. If you want to show all the other events between the interesting ones as well, add a partition by clause to the windowing function to highlight interesting events, and lose the where clause.
And yeah, vim is a good quick and easy way to explore data. So in postgres, add 'export PAGER="vim -"' to your ~/.psqlrc file, and your query results automatically pop up in vim (may want to switch to unaligned output in that case using the \a toggle).
For people not in the UK who don't know what that is...it's like showing off your new liquid Nitrogen GPU cooling system and your grandma saying "Oh that's nice dear, it's like the one the nurses put in the home last year".
I'd rather just believe that it's done by little elves running around.