Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous, ayant changé de SGBDR passant de MySQL à PostgreSQL j'ai voulu insérer une nouvelle colonne dans une table et je me suis aperçu que sous PostgreSQL ce n'était pas possible, la nouvelle colonne vient obligatoirement à la fin de la table.
Les différentes solutions que j'ai vues sont de recréer la table en copiant les données et en y mettant la nouvelle colonne dans l'ordre voulue.
Savez-vous si sur les prochaines versions de PostgreSQL cette problématique sera résolue et si cela va rester ainsi.
Merci à tous de vos réponses.
Hors ligne
A priori non, et pour une raison simple, cela n'a pas spécialement de sens de le faire. La seule raison réelle que je vois est de réagencer les colonnes pour gagner en performance et en espace disque. C'est une optimisation si spéciale et si rare que je la vois mal être prise comme suffisamment importante pour que cette fonctionnalité soit ajoutée.
Guillaume.
Hors ligne
Et aussi pour avoir une structure de table qui ressemble à quelque chose. En effet sur l'ensemble de mes tables je stocke la date de création et de modification de l'enregistrement avec un utilisateur de l'application. Ces champs sont toujours en fin de table. Lorsque j'insère un nouveau champ ce sera toujours avant ou après un autre champ et jamais à la fin. Aussi j'utilise une fonction qui me permet de voir si ma structure de base de données est cohérente en fonction de ma version et si j'ai des noms de champs disparates entre une base de données client et une autre ça va être compliqué de s'y retrouver. SQLServer et MySQL ont cette possibilité s'ils l'ont fait je pense sincèrement qu'il y a une bonne raison.
En tout cas merci d'avoir pris le temps de me répondre en espérant que cette fonctionnalité arrive un jour.
Hors ligne
Pour que cette fonctionnalité arrive dans PostgreSQL, il faudrait un développeur suffisamment intéressé, qui s'attelle à écrire le patch et à le défendre. Ce n'est pas la première fois que j'entends cette demande mais jusqu'à présent, personne n'a contracté un développeur pour le faire.
Guillaume.
Hors ligne
Bonjour,
Sinon si vous n'avez pas trop de volumes dans vos tables, vous pouvez toujours recréer votre table avec la colonne où vous voulez et reprendre les données ensuite.
Cordialement,
Sébastien.
Hors ligne
Oui j'entends bien c'est la solution proposée sur Stack mais c'était justement pour éviter cela.
Merci.
Hors ligne
Pensez-vous que moyennent rémunération cette fonctionnalité pourrait-elle sortir ? En effet le produit que je propose commercialement fonctionnait sous MySQL avec une notion de licence GPL que je ne peux donc pas commercialiser sans prendre de licence. A aujourd'hui le coût licence d'un MySQL ou MariaDB n'est pas viable pour mes clients d'où ma démarche de changer de SGBD pour PostgreSQL. Merci d'avance de vos réponses.
Hors ligne
Oui, il faudrait demander à un développeur de la coder. Ce sont des choses qui se font. Par contre, cette nouvelle fonctionnalité ne pourra être intégrée que dans la prochaine version de PostgreSQL (la 12 si c'est intégré avant mi mars, je dirais). De ce fait, vos clients ne pourraient pas utiliser de versions antérieures. Et il faut pour cela que la communauté accepte le patch proposé par ce développeur. Pas simple, mais faisable.
Guillaume.
Hors ligne
Ok je veux bien la marche à suivre pour cela. Lorsqu'une demande de nouveau patch est demandée, avez-vous des outils pour savoir combien de DBA et Développeurs cela pourrait intéresser (par rapport à l'obtention du patch) ? Parce que si c'est le cas et qu'on est plusieurs à financer j'imagine que ça pourrait être intéressant pour tout le monde, autant pour nous (coût moindre) que pour le développeur qui programmera le patch. Qu'en pensez-vous ?
Hors ligne
La première chose à faire, c'est de prendre connaissance des échanges que les développeurs PostgreSQL ont déjà eu sur ce sujet, pour évaluer la difficulté du problème. Il y a pas mal d'explications ici:
https://wiki.postgresql.org/wiki/Alter_column_position
(dont une bonne partie est "comment s'en passer", mais voir les liens à la fin de la page sur les discussions de "comment l'implémenter").
Il y a également cette discussion qui se réfère à un patch mais j'ai l'impression jamais envoyé (?):
https://www.postgresql.org/message-id/f … .gmail.com
Ca date de 2006-2007, mais il y a des chances que le problème principal posé par cette fonctionnalité soit le même aujourd'hui.
En version courte, le problème est qu'en interne Postgres se réfère à la position des colonnes dans la table en tant que clef primaire (attrelid, attnum), de telle manière que "décaler" ces positions remettrait en question un point de conception.
D'ailleurs une colonne supprimée garde son emplacement, elle n'est pas supprimée physiquement dans la couche de stockage.
La question qui se posera sur une remise en question de ce point de conception, c'est est-ce que ça vaut le coup? Les développeurs de Postgres font parfois des changements de conception importants, mais dans des cas où le retour sur investissement attendu est très significatif, comme par exemple le parallélisme intra-requête introduit par la version 9.6.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci pour votre réponse
Hors ligne
Pages : 1
