IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

PostgreSQL 9.5 est disponible en version bêta 1
Et intègre la correction de nombreux bogues signalés depuis la version alpha 2

Le , par Malick

204PARTAGES

10  0 

Le PostgreSQL Global Development Group a annoncé la sortie de la première version bêta de PostgreSQL 9.5. Cette dernière, selon l'éditeur, contient toutes les fonctionnalités et les API qui seront intégrées dans la version finale. Peu de modifications devraient intervenir.

L'éditeur affirme qu’avec cette première version bêta de PostgreSQL 9.5, les utilisateurs peuvent maintenant tester leurs applications, cela en préparation de la version finale.

Le PostgreSQL Global Development Group souligne également que cette nouvelle version du célèbre système de gestion de bases de données relationnelles et objets intègre plusieurs corrections de bogues qui avaient été signalés depuis la sortie de la version Alpha 2. Parmi les améliorations apportées, nous pouvons citer :
  • de nombreux ajustements à la sémantique du Row Level Security (RLS) ;
  • des améliorations des deadlocks avec LWLock ;
  • les problèmes de corruption d'index BRIN ;
  • les difficultés relatives à la connexion avec PGSSLMODE=require sous Windows ;
  • différents problèmes de traçage des timestamp de commit ;
  • les fuites de mémoire des hash join ;
  • le comportement incohérent de jsonb_set lors de l'ajout dans un tableau.

L'éditeur souligne également la modification de la sémantique du Row Level Security pour plus de cohérence avec le système de permissions de PostgreSQL basé sur GRANT. À titre d’exemple, la RLS applique désormais à la fois les politiques d'INSERT et SELECT lorsque l'INSERT RETURNING est utilisé. Ceci étant, les utilisateurs sont invités à tester l'application des règles TLS et à retester toute configuration RLS existante afin de s’assurer qu’il n’y a pas de régression dans leurs cas d'utilisation.

Le PostgreSQL Global Development Group ajoute que ceci est la première version bêta de la version 9.5 ; ce qui veut dire que très peu de changements visibles par l'utilisateur sont attendus avant la version finale. Le projet PostgreSQL publiera des bêtas supplémentaires requis pour les tests à venir, cela jusqu'à la sortie de la version finale prévue en fin de 2015.

Téléchargez PostgreSQL 9.5 bêta 1

Consultez la note de version

Source : annonce officielle

Et vous ?

Que pensez-vous de cette nouvelle version bêta ?
Allez-vous la tester ?

Voir aussi :

le Forum PostgreSQL

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de T`lash
Membre confirmé https://www.developpez.com
Le 14/01/2016 à 10:45
Avec l'instruction ON CONFLICT, on pourra remplacer ceci :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE FUNCTION upsert_user(u_name text, u_fullname text, u_email text) RETURNS integer
    LANGUAGE plpgsql
    AS $$
DECLARE
    userid users.id_user%TYPE;
BEGIN
    LOOP
        UPDATE users SET "fullname" = u_fullname, "email" = u_email WHERE "name" = u_name RETURNING "id_user" INTO userid;
        IF FOUND THEN
            RETURN userid;
        END IF;
        BEGIN
            INSERT INTO users ("name", "fullname", "email") VALUES (u_name, u_fullname, u_email) RETURNING "id_user" INTO userid;
            RETURN userid;
            EXCEPTION WHEN unique_violation THEN
                
        END;
    END LOOP;
END;
$$;

SELECT * FROM upsert_user(`jdoe`, `John Doe`, `john.doe@developpez.com`);
Par ceci :

Code : Sélectionner tout
1
2
3
4
INSERT INTO users ("name", "fullname", "email")
VALUES (`jdoe`, `John Doe`, `john.doe@developpez.com`)
ON CONFLICT DO UPDATE SET "fullname" = `John Doe`, "email" = `john.doe@developpez.com`
RETURNING "id_user";
L'avantage est de ne pas être obligé de passer par une procédure stockée.
Intéressant pour l'avenir, mais je ne vais pas pour autant modifier mes anciens projets.
3  0 
Avatar de al1_24
Modérateur https://www.developpez.com
Le 14/01/2016 à 12:46
Il me semble que la commande MERGE apparue dans la norme SQL-2003 opère de manière semblable.
Code : Sélectionner tout
1
2
3
4
5
MERGE INTO ma_table [AS] tgt
USING ( requete ) [AS] src
ON ( src.cle = tgt.cle )
WHEN MATCHED THEN UPDATE SET tgt.col = src.col [, ...]
WHEN NOT MATCHED THEN INSERT (cle, col [, ...]) VALUES (src.cle, src.col [, ...]);
Je trouve dommage d'avoir créé une commande spécifique plutôt que se conformer à la norme.
2  0 
Avatar de T`lash
Membre confirmé https://www.developpez.com
Le 14/01/2016 à 13:30
Il existe plusieurs raisons à cela, mais la principale est que PostgreSQL se veut un SGBDR collant parfaitement à la norme SQL, ce qui fait qu'ils n'implémentent une instruction que lorsqu'ils sont sûrs de le faire de la bonne manière.
Oracle et MSSQL utilisent la syntaxe du MERGE pour l'implémentation de l'UPSERT, mais la plupart des SGBDR ont préféré (comme c'est le cas pour PostgreSQL) de choisir un autre mot réservé car la norme SQL-2003 ne définit pas de manière précise le comportement de cette instruction.
Si ce comportement devait être détaillé dans une future norme, ils ne veulent pas que leur implémentation du MERGE n'entre en conflit avec cette norme.

Source : https://wiki.postgresql.org/wiki/UPS...tax_discussion

MERGE disadvantages

The SQL standard doesn't specify concurrency behaviour for MERGE any more than it does for INSERT, UPDATE, or DELETE; so (like other DML) our behavior with concurrent access may not be the same as other database products. In particular, the SQL standard does not require that MERGE be atomic in the sense of atomically providing either an INSERT or UPDATE, and other products do not provide any such guarantees with their MERGE statement.

The SQL-standard MERGE doesn't provide for choosing an index, so use of a unique index would need to be conditioned on equality quals against indexed columns in order to provide the behavior being discussed for UPSERT.

Implementing an extended subset of MERGE support for UPSERT will impact a future implementation of full MERGE support:
Different concurrency and locking semantics will be needed for a MERGE without equality quals matching a unique index of the target table.
Users may be very surprised when failure to compare for equality on the columns of a unique index results in slower execution or less graceful interaction with other transactions, such as deadlocks.
The design for MERGE when the conditions don't allow joining using a unique index has not yet been done. It may require different locking, allow deadlocks or other serialization failures, or allow the same anomalies which can occur with other DML statements, and which will not be possible when the unique index is used.

If a subquery (rather than a direct table reference) is used for the second relation reference, there is no restriction on what that subquery may join on. Delineating the cases where we must use a dirty snapshot, and where we must use an MVCC snapshot seems very difficult and subtle - Peter Geoghegan [14] [15].

The ON expression will need to be evaluated to see whether it properly compares to a unique index on the target table. Initially this will need to be done to determine whether the MERGE is allowed at all; later it will determine which sort of plan is allowed. It would be easier to match an index name, provided the index name is known and stable.

MERGE will probably need to fire before row insert triggers after deciding to insert, since in general it cannot reverse the triggers having been fired - the implementation should probably have decided on insertion by then. In contrast, UPSERT will have to fire before row triggers before deciding to INSERT or UPDATE (by value locking the value extracted from the affected tuple) [16]. With UPSERT, we are deciding to take the alternative path based on the modified tuple. With MERGE, we may prefer not to.
2  1 
Avatar de alassanediakite
Membre expert https://www.developpez.com
Le 15/01/2016 à 15:52
Salut
Citation Envoyé par MichaelREMY Voir le message
je suis désolé d'insister, mais je ne vois pas l'utilité.
Peut-être qu'on arrive pas à t'expliquer l'utilité de la chose, mais sache qu'on trouve "MERGE" dans SQL Server, ORACLE, DB2 MySQL, Firebird, PostgreSQL. Ce n'est pas pour rien que tout ces systèmes implémentent la même chose (chacun le faisant un peu en sa manière).
Dans ton cas(le changement de prénom), je reçoit la ligne (sur le csv) avec CLE et prénom: si la clé existe alors je mets à jour sinon j’insère CLE et prénom.
Voir ici.
1  0 
Avatar de MichaelREMY
Membre éclairé https://www.developpez.com
Le 08/01/2016 à 16:26
UPSERT sert-elle à mettre à jour un enregistrement dans le cas où l'insertion serait un échec dû à un duplicat ?

ou est-ce l'inverse ? c-a-d UPSERT permet de créer un tuple si on a essayé avec échec de mettre à jour un enregistrement dont l’id n'existe pas-plus ?

Dans les deux, n'est-ce pas de la responsabilité du "bon développeur responsable" de s'assurer de l'existence ou de la non-existence d'un tuple (ou de son id) avant sa mise-à-jour/création.
0  0 
Avatar de Shepard
Membre expérimenté https://www.developpez.com
Le 09/01/2016 à 20:49
La commande en PostGreSQL ne s'appelle pas UPSERT mais "ON CONFLICT UPDATE", qui est bien plus explicite je pense :-)

Le cas d'utilisation est simplement lorsqu'on veut s'assurer que la donnée se trouvera dans la base de données, peu importe si elle était déjà présente ou pas. C'est parfois pratique, mais ça ne reste "que" du sucre syntaxique .
0  0 
Avatar de dasdeb
Membre actif https://www.developpez.com
Le 14/01/2016 à 1:50
Pour moi ça ressemble au INSERT... ON DUPLICATE UPDATE de MySQL, qui existe depuis longtemps
0  0 
Avatar de MichaelREMY
Membre éclairé https://www.developpez.com
Le 14/01/2016 à 11:01
quelqu'un peut-il me dire dans quel cas fonctionnel, quelle situation (dans la vie réelle, dans une vraie application développée sérieusement), on arrive à un cas où l'on met à jour un enregistrement qui n'est pas existant (qui n'a pas d'id) ?

ça semble être un moyen de dissimuler/amortir un bug produit dans l'application (qui met à disposition des enregistrements sans ID alors qu'elle ne devrait pas) ?
Quelle situation de la vie d'un processus autoriserait un tel process : créer un ID quand une identité n'existe pas ... c'est bancal non ?

Si on met à jour un enregistrement et que l'id n'existe pas, la moindre des choses est de retourner une erreur pour enquêter de la disparition de cet ID (ou du filtrage écran trop strict) plutôt que de recréer une identité.
0  0 
Avatar de T`lash
Membre confirmé https://www.developpez.com
Le 14/01/2016 à 12:33
Tu utilises généralement l'UPSERT pour intégrer un objet d'une base de données externe à ta base.
Je l'utilise par exemple dans le cas de l'authentification Active Directory à l'IntraWeb PHP de la société : si l'utilisateur se connecte pour la première fois au système son nom de compte n'existe pas au sein de la base de données, mais tu cherches à obtenir la clé primaire dans la table users. Dans ce cas l'UPSERT insert une ligne et te renvoie l'id de la ligne insérée. Lorsqu'il se connectera pour la seconde fois il te renverra l'id de la ligne existante. Il en va de même pour les groupes auxquels cet utilisateur appartient, qui doivent exister localement pour servir au système de gestion d'accès de l'appli alors que leur création, modification et suppression ne se fait que dans Active Directory.

Certains dans ce cas utiliseront deux requêtes distinctes et diront que l'UPSERT ne sert à rien, mais imagine un cas pratique très simple : le verrouillage du formulaire de login est défaillant et la requête est envoyée à deux reprises dans un intervalle très court (double clic sur le bouton d'envoi). Nous aurons donc 2 accès concurrents qui vont vérifier l'existence du nom d'utilisateur et chercher à le créer. Le premier réussira, mais le second va lever une exception. Pour faciliter cela on peut, grâce à l'implémentation du concept UPSERT (ON CONFLICT DO), gérer tout cela en une seule opération : insérer, sinon mettre à jour ou simplement récupérer.
0  0 
Avatar de MichaelREMY
Membre éclairé https://www.developpez.com
Le 14/01/2016 à 17:01
Citation Envoyé par T`lash Voir le message
Je l'utilise par exemple dans le cas de l'authentification Active Directory à l'IntraWeb PHP de la société : si l'utilisateur se connecte pour la première fois au système son nom de compte n'existe pas au sein de la base de données, mais tu cherches à obtenir la clé primaire dans la table users. Dans ce cas l'UPSERT insert une ligne et te renvoie l'id de la ligne insérée. Lorsqu'il se connectera pour la seconde fois il te renverra l'id de la ligne existante. Il en va de même pour les groupes auxquels cet utilisateur appartient, qui doivent exister localement pour servir au système de gestion d'accès de l'appli alors que leur création, modification et suppression ne se fait que dans Active Directory.
donc tu as deux tables d'utilisateurs, c'est répétitif et dangereux sur le point de la sécurité. pourquoi ne pas avoir ajouter à ton intraweb la possibilité d'aller lire l'active directory plutôt que de le redondancer comme ça ? ou de créer une VUE ?

quand une nouvelle personne arrive dans l'entreprise, vous l'inscrivez dans l'activedirectory, mais pas dans votre intranet ? pourquoi ?
0  0