Renommer une table en la suffixant par l'année

Bonjour,

J'aimerai pouvoir, en quelque sorte, archiver une table en la suffixant par l'année avant d'enregistrer la table de l'année en cours.
J'ai fait quelques tests, j'arrive à afficher le nom de la table que j'aimerai ...
Mais pas à en faire le nom de ma table

Code:

---

1 2 3 4 5

select 'nom_table' || '_'||extract(year from now())-1; --qui me donne: nom_table_2018 ALTER TABLE nom_table RENAME TO select 'nom_table' || '_'||extract(year from now())-1;

---

J'ai vu des assignations de variable du style

Code:

---

1 2 3 4

matable:='nom_table' || '_'||extract(year from now())-1 ALTER TABLE nom_table RENAME TO matable;

---

Mais c'est encore un échec.

Existe-t-il une solution simple à mon problème qui me fera me mettre une claque de pas y avoir pensé ?
Ou faut-il passer par des solutions plus compliquées que du simple sql des familles ?

Merci

La solution se trouve bien dans le SQL : c'est la commande EXECUTE IMMEDIATE;)

Wouhaa 8O jamais entendu parler avant, mais en même temps je suis resté à du sql ultra basique jusqu'à maintenant.

Bon déjà merci de la réponse rapide !!
Ensuite, je vais me pencher un peu dessus mais une rapide lecture de la doc m'a fait mal au crane.
Mon niveau en sql fait que je vais y passer un peu de temps demain à mon avis.
Si c'est pas trop couteux pour toi je veux bien une solution toute faite :mrgreen:
Sinon ben ce sera tempête de cerveau.

En tout cas merci, je reviens sur le forum pour supplier de l'aide si j'échoue ou clôturer sinon.

Rien de très compliqué

Code:

---

EXECUTE IMMEDIATE 'ALTER TABLE ' || :nom_table || ' RENAME TO ' :nom_table || '_' || extract(year from now()) -1;

---

Malheureusement ça ne fonctionne pas chez moi.

ERROR:  ERREUR:  erreur de syntaxe sur ou près de « 'ALTER TABLE' »
LINE 2: EXECUTE IMMEDIATE 'ALTER TABLE'  || :installations_sportif |...
                                       ^

J'ai testé plusieurs syntaxes mais quoi que je mette après execute immediate je me fais jeter.
Je dois mettre cette instruction dans une fonction? dans un bloc begin end?

édit: le "^" est juste en dessous de l'apostrophe avant ALTER

Bonjour,

Pourquoi vouloir renommer la table avec pour conséquence la nécessité de modifier les requêtes qui y accèdent...

Quel est le besoin fonctionnel ?

Bonjour escartefigue,

Comme précisé dans mon 1er message, l'objectif est d'archiver automatiquement les millésimes année par année de ma table.

Dans mon schéma j'ai une table sans suffixe qui est la table actuelle, et des tables avec l'année en suffixe pour les années passées.
Comme la table de référence avec les données à jour sera toujours celle sans suffixe il n'y aura jamais le problème de requête que tu soulèves.
ex: table, table_2018, table_2017 ...
en 2020, le but est de transformer table en table_2019
et d'enregistrer la nouvelle en table.
Je ne peux malheureusement pas ajouter une colonne année, ce serait trop simple :(
la structure de la table ne doit pas changer

Ca ne répond pas à ma question : pourquoi archiver les données des années antérieures ? pour des problèmes de performances ? pour d'autres raisons ?
Il existe sans doute d'autres solution techniques si c'est la performance qui est recherchée, sauf si vous êtes certains qu'une fois l'année échue, on n'ira plus jamais consulter ces tables avec les requêtes habituelles. Ce qui me semble peu probable.

Pour de simples question légales je DOIS conserver les anciennes données.

... mais ... ça ne répond toujours pas à la question : conserver les anciennes données n'impose en aucun cas de les mettre dans une autre table !
Si le souhait est d'optimiser les traitements, il est possible par exemple de partitionner la table (qui reste unique) sur le critère année.
Le critère de partitionnement pouvant être modifié quand nécessaire, on peut imaginer par exemple une partition pour l'année en cours, une pour A-1, une pour A-2, une pour A-3 et une dernière pour tout ce qui est antérieur.

Comment tu fais une partition sur la table s'il n'y a pas de date dans les données? et sans créer une nouvelle colonne?

Sinon, il n'y a aucune notion d'optimisation dans l'histoire.

Je dois juste conserver les anciennes données, et je ne dois pas changer la structure de ma table.
Je pensais naïvement que je pouvais en quelques lignes déclarer une variable, lui affecter une valeur et utiliser cette variable comme nom pour ma table.
Le "exectute immediate" est sans doute une très bonne piste mais je coince dans la syntaxe.

Mais si tu as une solution simple pour résoudre mon problème d'une autre manière je suis super preneur, c'est juste que techniquement je suis assez léger dès qu'on sort du sql très basique, et que selon ta solution j'aurais sans doute besoin de revenir vers toi.

Sinon j'ai pensé à créer une nouvelle table et y copier le contenu de l'ancienne puis la supprimer et importer les nouvelles données, mais le problème est le même, je ne sais pas comment créer ma nouvelle table avec l'année en suffixe dynamiquement ...

Effectivement si le critère date est absent des données, pas de partitionnement possible.

En ce cas, une autre solution possible est l'utilisation de schémas, solution qui n'a d'intérêt que si vous devez utiliser, au moins de temps à autres, les données des années précédentes.

schema_encours.ma_table : données de l'année A
schema_moins1.ma_table : données de l'année A-1
schema_moins2.ma_table : données de l'année A-2
etc.

Ensuite, selon que le traitement utilise les données de A, A-1 ou A-n, on positionne le schéma par SET search_path TO xxxxx.

Sauf que cette solution nécessite la recopie de A-2 dans A-3, puis A-1 dans A-2 et A dans A-1 lors du changement d'année. Pas très pratique.
Et que si un traitement veut consulter les données de plusieurs années, ça ne fonctionne pas :?
Solution sur le même principe et qui permet de consulter si besoin toutes les années sauf l'année en cours : un schéma pour l'année en cours, un autre unique pour toutes les autres années.
Plus souple à l'utilisation.
Par contre, avec les schémas, le nom de la table ne change pas : les traitements, fonctions, triggers et autres requêtes fonctionnent sans adaptation préalable :)
À voir donc selon le besoin.

Honnêtement je pensais poser une question toute bête et que la syntaxe ferait deux lignes:

Comment je déclare une variable, que je la remplie avec un select et que j'utilise cette variable comme nom de ma table?

Les solutions que tu me proposes sont intéressantes mais ne répondent pas à mon problème.
Mais si c'est trop compliqué je vais chercher d'autres outils que SQL pour faire ça.

La solution proposée par AL1__24 fonctionne, mais en ce cas il faut également utiliser du SQL dynamique pour les requêtes de façon à accoler l'année au nom de la table.
Attention toutefois : le SQL dynamique est interdit sur certains sites de production et il est parfois source de lenteurs

Sa solution fonctionne probablement sous certaines conditions ou en ajoutant un truc quelque part, mais tel quel ça me génère une erreur.

Je m'en suis sorti en faisant une fonction

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

CREATE OR REPLACE FUNCTION nom_schema.majTable(adresse_table character varying, nom_table character varying) RETURNS text LANGUAGE plpgsql   AS $function$   declare madate text; matable character varying; req text;   begin --on stocke la date de l'année précédente madate=extract( year from now())-1; --on créé le nom de l'archive matable=nom_table||'_'||madate; --on construit la requête req := 'ALTER TABLE ' || adresse_table || ' RENAME TO ' || matable || ';'; --on execute la requête EXECUTE(req); RETURN TRUE; END; $function$ ;

---

Si quelqu'un l'utilise, il faudrait ajouter un test pour savoir si la table existe avant de la renommer, sinon ça plante.