tl;dr
Maintenant dans Postgres 10, spécifiez GENERATED BY DEFAULT AS IDENTITY
selon la norme SQL.
create table tower
(
npages integer,
ifnds integer,
ifnid integer,
name varchar(20),
towid integer GENERATED BY DEFAULT AS IDENTITY -- per SQL standard
)
Colonne d'identité
Postgres 10 prend désormais en charge le concept de colonne d'identité , et utilise la syntaxe SQL standard. Bien que je ne sois pas un expert de MS SQL Server, je pense que ce nouveau support standard est équivalent.
GENERATED … AS IDENTITY
Le GENERATED … AS IDENTITY
commande utilisée pendant CREATE TABLE
crée une séquence implicite. La création, le nommage, les autorisations et la suppression de cette séquence sont transparents pour vous, contrairement à SERIAL
. Très intuitif maintenant. Si vous accordez une autorisation d'utilisation à la table, ils obtiennent l'autorisation pour la séquence. Si vous supprimez la table, la séquence est supprimée automatiquement.
Deux variantes de la syntaxe standard. La différence n'a d'importance que si vous transmettez une valeur plutôt que de laisser une valeur être générée. En règle générale, les gens s'appuient toujours sur la valeur générée, donc normalement vous utiliserez simplement la première version, GENERATED BY DEFAULT AS IDENTITY
.
GENERATED BY DEFAULT AS IDENTITY
- Génère une valeur sauf si
INSERT
la commande fournit une valeur.
- Génère une valeur sauf si
GENERATED ALWAYS AS IDENTITY
- Ignore toute valeur fournie par
INSERT
sauf si vous spécifiezOVERRIDING SYSTEM VALUE
- Ignore toute valeur fournie par
Voir le CREATE TABLE
page de documentation.
Lisez cette page intéressante
par Peter Eisentraut. Il explique quelques problèmes étranges avec SERIAL
. Aucun problème de ce type avec la nouvelle fonctionnalité de colonne d'identité. Il n'y a donc aucune raison d'utiliser SERIAL
plus, pas d'inconvénients, seulement des avantages ; SERIAL
est remplacé par GENERATED … AS IDENTITY
.
Notez qu'une colonne d'identité n'est pas nécessairement une clé primaire et n'est pas automatiquement indexée. Vous devez donc toujours spécifier PRIMARY KEY
explicitement si telle est votre intention (comme c'est généralement le cas).
CREATE TABLE person_ (
id_
INTEGER
GENERATED BY DEFAULT AS IDENTITY -- Replaces SERIAL. Implicitly creates a SEQUENCE, specified as DEFAULT.
PRIMARY KEY -- Creates index. Specifies UNIQUE. Marks column for relationships.
,
name_
VARCHAR( 80 )
) ;
L'intention est que les détails d'implémentation internes vous soient cachés. Vous n'avez pas besoin de connaître le nom de la séquence générée sous les couvertures. Par exemple, vous pouvez réinitialiser le compteur via la colonne sans connaître la séquence sous-jacente.
ALTER TABLE person_
ALTER COLUMN id_
RESTART WITH 1000 -- Reset sequence implicitly, without a name.
;
Spécification implicite de l'identité :
- Colonne des marques
NOT NULL
- Crée une séquence
- Le type de séquence correspond à la colonne (32 bits 64 bits, etc.)
- Lie la séquence à la colonne
- Hérite des autorisations
- Cascades tombantes
- Reste lié à la colonne même si la colonne est renommée
- Spécifie la séquence comme source des valeurs par défaut pour cette colonne
La colonne d'identité peut prendre les mêmes options que CREATE SEQUENCE
:
START WITH start
MINVALUE minvalue
|NO MINVALUE
MAXVALUE maxvalue
|NO MAXVALUE
INCREMENT [ BY ] increment
CYCLE
|NO CYCLE
CACHE
cacheOWNED BY NONE
( spécifier la propriété pour la colonne d'identité n'a aucun sens pour moi car la propriété est gérée automatiquement)
Exemple idiot d'options :
id_ INTEGER
GENERATED BY DEFAULT AS IDENTITY (
START WITH 200
MINVALUE 100
MAXVALUE 205
CYCLE
INCREMENT BY 3
) PRIMARY KEY
Ajout de 4 lignes :