I definitely agree that simply tracking message sequence numbers on both sides is better. It's also a powerful feature to be able to cancel all messages "up to N" - I'm thinking of a scenario where, for example, many simple queries are sent and the whole process needs to be cancelled.
For security, I think any non-matching cancellation would be ignored so that only someone with proper context could issue the cancel.
Isn't security taken care of by the secret key?
Issuing bulk cancellations sounds like a bad plan.
I'm not sure why, but at the very least it's a useful thing to have when batching several statements together and then wanting to cancel them all.
Yes, this has been happening to some Npgsql users, it's not very frequent but it does happen from time to time. I also bumped into this in some automated testing scenarios. It's not the highest-value feature, but it is an improvement to have if you plan on working on a new protocol version.
Let me know if you'd like me to update the TODO.
If you've got an itch, expecting someone else to scratch it is less likely to succeed.
Sure. I'd consider sending in a patch, but as this is a protocol-changing feature it seems like working on this before the team "officially" starts working on a new protocol might be a waste of time. Once there's critical mass for a new protocol and agreement that PostgreSQL is going for it I'd be happy to work on it.
BTW it seems it's no longer possible for anyone to add things to the TODO (no editor privileges).
