Galette

Bah, difficile de prédire quelle sera la taille préconisée dans gpg3 ou gpg4. Je dirais donc que 50 seraient en effet suffisants (ou 40 à la rigueur).
Cela dit, ce que je recommanderais, c'est de normaliser en supprimant les espaces avant de stocker.

Exemple de sortie avec espaces (apt-key list sur une Debian) :

pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
      126C 0D24 BD8A 2942 CC7D  F8AC 7638 D044 2B90 D010

ou ma propre clef (gpg2 --list keys)

pub   rsa4096 2017-05-14 [SC]
          BF5456F4DC625443849B6E58EE20CA44EF691D39

Et comme remarque finale, j'ajouterai qu'en PostgreSQL, varchar(length) n'est jamais que la même chose que text avec une contrainte en plus. Ça n'a pas d'incidence sur le stockage et donc n'est utile que pour l'applicatif, et non pour la base elle-même (je crois que c'est différent avec d'autres SGBD). Si jamais il y a moyen d'éviter des contraintes non souhaitées applicativement sans nuire à l'uniformité…

Georges Racinet a écrit :

Bah, difficile de prédire quelle sera la taille préconisée dans gpg3 ou gpg4. Je dirais donc que 50 seraient en effet suffisants (ou 40 à la rigueur).
Cela dit, ce que je recommanderais, c'est de normaliser en supprimant les espaces avant de stocker.

Cela ne nuira-t-il pas à la "lisibilité" ?

Et comme remarque finale, j'ajouterai qu'en PostgreSQL, varchar(length) n'est jamais que la même chose que text avec une contrainte en plus. Ça n'a pas d'incidence sur le stockage et donc n'est utile que pour l'applicatif, et non pour la base elle-même (je crois que c'est différent avec d'autres SGBD). Si jamais il y a moyen d'éviter des contraintes non souhaitées applicativement sans nuire à l'uniformité…

Ha tiens, je ne savais pas... En MySQL ; il me semble que ce sont deux choses bien distinctes... Mais bon ; je ne pense pas qu'on en soit encore aujourd'hui à regarder à l'octet près en ce qui concerne la base ; il serait donc envisageable de passer ce chmp en text ; et ne plus avoir de problème de limité à l'avenir, oui.