The purpose of constraints is to improve data integrity. By "integrity" I mean accuracy, internal consistency, and faithful assertion of business requirements for which the database serves.
So, I'm pleased you included the word "suggesting" in your title. The best way (only way, perhaps) to ascertain business requirements is through dialog with the stake holders.
First of all, it's not sufficient to determine a primary key constraint--all (minimal) unique keys that are important to the business should be identified and enforced with constraints. While choosing which is the best candidate for the primary key, is perhaps a matter of technical preference, identifying the candidates certainly is not.
Relying on data types, column names, and content patterns assumes the database was designed with best practices and already exhibits a high degree of integrity. That's seldom the situation I encounter.
FWIW, your scripts are interesting and useful. But, I would rather see a process that agrees upon appropriate constraints in logical dialog with the stake holders and scripts that subsequently expose missing database constraints and content violations.