paperplatter

The easiest fix for this is the "WHERE 1=1" or "WHERE true"

1=1 is not a security risk

I get how this isn't good. But how else would you handle multi-field filtering, keep all the ANDs and use (product_id = $1 OR $1 IS NULL) so the unset filters are no-op? That's ok as long as the query planner is smart enough.

Yeah, so often do I have an EXPLAIN ANALYZE query.txt file I'm repeatedly editing in one window and piping into psql in another to try and make something faster. So I put WHERE true at the top.

Sounds like that DBMS would work better with serial int PKs

I feel like residential ipv6 would be at least a little further along if routers simply always enabled NAT by default for it, like what cell providers do. Solves all these questions and problems for inexperienced users. Instead, you gotta ask, is the firewall enabled and default-deny, are ULAs enabled...

RFC 2765 isn't about keeping ipv4 blocks in ipv6, if I understand correctly. It's about translator boxes for ipv6-only hosts to talk to ipv4-only ones by acquiring temporary ipv4 addresses.

4-to-5 NAT would be effectively the same if that's what you use, but I don't see why you'd need one.

Hm. Tempted to try pytorch on my Mac for this. I have an AS chip rather than a Nvidia GPU.

I agree then, the defaults are a problem.

The second thing is the problem with not having NAT. On a home or corp network, I like NAT. I'm not trying to host 20 servers there. Sure ipv6 can use it too, but it's never default and often not supported on the router.

So yeah, 192.168.1.55 is my Mac's local ip, it's easy to remember.

But you're still using ipv4, which cannot be upgraded in-place the way I described. I responded to a sibling comment about the second question.

You still make the same big changes, but the difference is you don't have to do them all at the same time. You also skip the complicated add-ons of ipv6 and don't reassign everything.

Ipv5 as you call it: Phase 1 is getting routers/hosts to understand v5 headers, while users enable v5 and change nothing else. Phase 2 is the transition where people keep using padded addrs while things* are updated in-place to just support longer ones, which doesn't affect users**. Once that's done, we get to use the full space, which some users may ignore and some may use. For better and worse, the existing /32 blocks would still be around initially. Maybe this would appeal to previous ipv4 holders better; they still own the same % of the pie. Maybe 8.8.8.8 would stay forever.

What makes me kinda sure would've worked? Right now, the world has mostly already completed the equivalent of phases 1 and 2 for ipv6. There might even be a way to reuse the ipv6 protocol as-is for ipv5.

* DNS, NAT, DHCP, ARP, routers, VPSes, OSes...

** "User" includes corp network admins, cloud/datacenter operators, ISPs, and simple home customers.