Comment voulez-vous créer une chaîne de caractères aléatoires qui convient à un ID de session dans PostgreSQL?

Vous pouvez fixer votre première tentative comme ceci:

SELECT md5(random()::text);

Beaucoup plus simple que celle de certains autres suggestions. 🙂

Vous pouvez obtenir 128 bits aléatoires à partir d'un UUID. C'est la méthode pour obtenir le travail fait dans la moderne PostgreSQL.

CREATE EXTENSION pgcrypto;
SELECT gen_random_uuid();

           gen_random_uuid            
--------------------------------------
 202ed325-b8b1-477f-8494-02475973a28f

Peut être intéressant de lire les docs sur l'UUID de trop

Le type de données uuid magasins Universellement Identificateurs Uniques (UUID), tel que défini par RFC 4122, ISO/CEI 9834-8:2005, et des normes connexes. (Certains systèmes de référer à ce type de données comme un identifiant unique, ou le GUID, à la place.) Cet identifiant est un 128 bits qui est généré par un algorithme choisi, il est très peu probable que le même identifiant sera généré par quelqu'un d'autre dans l'univers connu en utilisant le même algorithme. Par conséquent, les systèmes distribués, les identificateurs de fournir une meilleure unicité de garantir que la séquence des générateurs, qui sont seulement unique au sein d'une seule base de données.

Comment rare, c'est une collision avec l'UUID, ou deviner? En supposant qu'ils sont aléatoires,

Environ 100 trillions de version 4 Uuid devrait être généré pour avoir un 1 sur un milliard de chance qu'une seule double ("collision"). Les chances d'une collision s'élève à 50% seulement après 261 Uuid (2,3 x 10^18 ou 2.3 quintillion) ont été générés. Rapportant ces chiffres à des bases de données, et compte tenu de la question de savoir si la probabilité d'une Version 4 de l'UUID de la collision est négligeable, envisager un fichier contenant 2.3 quintillion Version 4 Uuid, avec 50% de chance de contenir un UUID de la collision. Il serait 36 exaoctets en taille, en supposant l'absence d'autres données ou des frais généraux, des milliers de fois plus grande que la plus grande des bases de données actuellement en existence, qui sont de l'ordre de plusieurs pétaoctets. Au taux de 1 milliard de dollars Uuid généré par seconde, il faudrait 73 ans, afin de générer les Uuid pour le fichier. Il serait également besoin d'environ 3,6 millions de 10 to de disques durs ou les cartouches de bande pour le stocker, en supposant qu'aucun des sauvegardes ou de la redondance. La lecture du fichier de type "disque-à-tampon" taux de transfert de 1 gigabit par seconde aurait besoin de plus de 3000 ans pour un processeur unique. Depuis le irrécupérable taux d'erreur de lecture de disques 1 bit par 1018 bits lus, au mieux, alors que le fichier contient environ 1020 bits, il suffit de lire le fichier une fois du début à la fin le résultat serait, au moins, dans environ 100 fois plus de mal lu Uuid que des doublons. Le stockage, le réseau, la puissance, et d'autres matériel et des logiciels des erreurs serait sans aucun doute des milliers de fois plus fréquente que l'UUID de la duplication des problèmes.

source: wikipédia

En résumé,

• UUID est normalisé.
• gen_random_uuid() est de 128 bits aléatoires stockées dans 128 bits (2**128 combinaisons). 0-déchets.
• random() ne génère 52 bits de hasard dans PostgreSQL (2**52 combinaisons).
• md5() stockées comme l'UUID est de 128 bits, mais il ne peut être aussi aléatoire que son entrée (52 bits si vous utilisez random())
• md5() stockés en tant que texte est de 288 bits, mais elle ne peut être aussi aléatoire que son entrée (52 bits si vous utilisez random()) - plus de deux fois la taille d'un UUID et une fraction de l'aléatoire)
• md5() d'un algorithme de hachage, peut être optimisé qu'il n'a pas effectivement faire beaucoup.
• UUID est très efficace pour le stockage: PostgreSQL fournit un type qui est exactement 128 bits. Contrairement à text et varchar, etc qui stockent comme un varlena qui dispose d'une charge pour la longueur de la chaîne.
• PostgreSQL chouette UUID est livré avec certains opérateurs par défaut, la fonte et les fonctionnalités.

Tout n'est pas actif par défaut, vous pouvez activer l'une des principales extensions:

CREATE EXTENSION IF NOT EXISTS pgcrypto;

Ensuite votre déclaration devient un simple appel à gen_salt() qui génère une chaîne de caractères aléatoires:

select gen_salt('md5') from generate_series(1,4);

 gen_salt
-----------
$1$M.QRlF4U
$1$cv7bNJDM
$1$av34779p
$1$ZQkrCXHD

Le premier numéro est un hachage de l'identificateur. Plusieurs algorithmes sont disponibles, chacun avec leur propre identifiant:

• md5: $1$
• bf: $2a$06$
• des: pas d'identifiant
• xdes: _J9..

Plus d'informations sur les extensions:

• pgCrypto: http://www.postgresql.org/docs/9.2/static/pgcrypto.html
• Inclus Extensions: http://www.postgresql.org/docs/9.2/static/contrib.html

---

MODIFIER

Comme indiqué par Evan Carrol, comme de v9.4 vous pouvez utiliser gen_random_uuid()

http://www.postgresql.org/docs/9.4/static/pgcrypto.html

Je ne pense pas que vous êtes à la recherche pour une chaîne de caractères aléatoires en soi. Ce que vous auriez besoin pour la session de vérification est une chaîne qui est garanti pour être unique. Stockez-vous de la session de vérification de l'information pour l'audit? Dans ce cas, vous avez besoin de la chaîne pour être unique entre les sessions. Je connais deux, plutôt approches simples:

1. Utiliser une séquence. Bon pour une utilisation sur une seule base de données.
2. Utiliser un UUID. Universellement unique, donc de bonne qualité sur les environnements distribués, trop.

Uuid sont garanti être unique, en raison de leur algorithme pour la génération; c'est extrêmement peu probable que vous allez générer deux nombres identiques sur n'importe quel ordinateur, à tout moment, jamais (à noter que c'est beaucoup plus fort que sur des chaînes aléatoires, qui ont une bien plus petite périodicité des Uuid).

Vous devez charger le uuid-ossp extension à utiliser des Uuid. Une fois installé, l'appel de l'uuid_generate_vXXX() les fonctions de votre sélection, d'INSERTION ou de mise à JOUR. L'uuid type est de 16 octets chiffre, mais il a aussi une représentation de chaîne.

L'ENTIER paramètre définit la longueur de la chaîne. Garantit la couverture de tous les 62 numérique des caractères avec la même probabilité (contrairement à certains autres solutions flottant autour sur l'Internet).

CREATE OR REPLACE FUNCTION random_string(INTEGER)
RETURNS TEXT AS
$BODY$
SELECT array_to_string(
    ARRAY (
        SELECT substring(
            '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
            FROM (ceil(random()*62))::int FOR 1
        )
        FROM generate_series(1, $1)
    ), 
    ''
)
$BODY$
LANGUAGE sql VOLATILE;

select encode(decode(md5(random()::text), 'hex')||decode(md5(random()::text), 'hex'), 'base64')