Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je suis confronté à un contexte de séquences que je ne comprends pas car j'obtiens des résultats qui me paraissent incohérents :
dans psql (comme dans PgAdmin)
bd1=# select * from information_schema.sequences where sequence_name like 't1%';me renvoie
-[ RECORD 1 ]-----------+------------------------
sequence_catalog | bd1
sequence_schema | test
sequence_name | t1_id_seq
data_type | bigint
numeric_precision | 64
numeric_precision_radix | 2
numeric_scale | 0
start_value | 8
minimum_value | 1
maximum_value | 9223372036854775807
increment | 1
cycle_option | NO
-[ RECORD 2 ]-----------+------------------------
sequence_catalog | bd1
sequence_schema | test
sequence_name | t1_mslink_seq
data_type | bigint
numeric_precision | 64
numeric_precision_radix | 2
numeric_scale | 0
start_value | 1000149
minimum_value | 1
maximum_value | 9223372036854775807
increment | 1
cycle_option | NOet
bd1=# select currval('t1_id_seq');
ERREUR: la valeur courante (currval) de la séquence « t1_id_seq » n'est pas encore définie dans cette session
bd1=# select currval('t1_mslink_seq');
ERREUR: la valeur courante (currval) de la séquence « t1_mslink_seq » n'est pas encore définie dans cette sessiontandis que PgAdmin m'indique
CREATE SEQUENCE test.t1_id_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 285
CACHE 1;
ALTER TABLE test.t1_id_seq
OWNER TO usr1;
CREATE SEQUENCE test.t1_mslink_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1000233
CACHE 10;
ALTER TABLE test.t1_mslink_seq
OWNER TO usr1;Ceci, sans que les séquences en question n'aient été modifiées ou utilisées depuis l'ouverture de session.
Pourquoi PgAdmin affiche-t-il une valeur différente de start_value pour l'option START ?
Merci d'avance
Dernière modification par jmarsac (14/04/2017 10:50:18)
Hors ligne
currval n'est utilisable dans une session qu'à partir du moment où nextval a été utilisée.
Quant aux différences entre information_schema.sequences et pgAdmin... information_schema.sequences étant une vue, dont la définition peut changer entre les versions de PostgreSQL, il serait bon d'indiquer cette version. Et pour pgAdmin, il se réfère aux catalogues systèmes PostgreSQL et non pas aux données contenues dans information_schema mais il est connu pour avoir des bugs et donc sa version serait aussi un plus...
Guillaume.
Hors ligne
Merci Guillaume.
Oui, j'avais mis le résultat de currval pour compléter l'information sur le contexte
Postgres 9.3
PgAdmin 1.22.2
Hors ligne
J'ai la même information entre PostgreSQL et pgAdmin sur mon poste. Seriez-vous connecté à un esclave dans le cas d'un cluster de réplication en streaming ?
Guillaume.
Hors ligne
Non, il s'agit d'une instance de test isolée en localhost.
OS: Win7 64 bits
Postgres 9.3 (32 bits) et PgAdmin 1.22.2 (32 bits) sont sur la même machine.
J'ai fait une copie d'écran (autant pour me rassurer sur mon constat que pour vous convaincre !) 
Hors ligne
Pas besoin d'être convaincu, je trouve ça étonnant et je n'ai pas de réponse.
Guillaume.
Hors ligne
Ok, merci. S'agissant d'une base de test, je vais me contenter de tout réinitialiser.
Hors ligne
Pourquoi réinitialiser ?
Votre séquence ne sert-elle pas qu'à assurer l'unicité de votre clé primaire ?
Hors ligne
J'ai refait quelques test et obtenu l'explication grâce à l'exécution du code suivant.
set search_path to public;
\x on
drop table if exists t1 cascade;
create table t1 (id bigserial primary key,nom character varying);
insert into t1 values (1,'A'),(2,'B'),(3,'C');
------
select currval('t1_id_seq');
select sequence_catalog, sequence_schema, sequence_name,data_type,start_value,minimum_value,maximum_value,"increment" from information_schema.sequences where sequence_schema = 'public' and sequence_name like 't1%seq';
------
select setval('t1_id_seq',3);
select currval('t1_id_seq');
select sequence_catalog, sequence_schema, sequence_name,data_type,start_value,minimum_value,maximum_value,"increment" from information_schema.sequences where sequence_schema = 'public' and sequence_name like 't1%seq';
------
insert into t1 (nom) values ('*A'),('*A1'),('*A2'),('*A3');
select currval('t1_id_seq');
select sequence_catalog, sequence_schema, sequence_name,data_type,start_value,minimum_value,maximum_value,"increment" from information_schema.sequences where sequence_schema = 'public' and sequence_name like 't1%seq';En fait, l'erreur "apparente" est due à une lecture erronée de ma part.
J'ai confondu l'option START affichée par PgAdmin dans le script SQL de création avec la valeur start_value donnée à la création de la séquence:
CREATE SEQUENCE public.t1_id_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 7
CACHE 1; ce code SQL permet de recréer la séquence pour qu'elle soit identique à son état actuel. Il est donc normal qu'il fasse démarrer la séquence à 7 en utilisant currval('t1_id_seq') puisqu'elle est définie; tandis que la vue information_schema.sequences affiche les valeurs utilisées pour créer la séquence existante.
Désolé pour le dérangement.
Dernière modification par jmarsac (14/04/2017 09:42:25)
Hors ligne
Pourquoi réinitialiser ?
Votre séquence ne sert-elle pas qu'à assurer l'unicité de votre clé primaire ?
L'idée était de repartir de zéro pour mes tests en considérant que ma base était peut-être incohérente, mais mon post précédent montre que l'incohérence était seulement dans ma tête ! ;-)
Hors ligne
Pages : 1