Bonjour à tous,

Petite prise de tête du vendredi
Je suis en Postgres v11.5 sous CentOS.

Je veux écrire un trigger qui lors d'un update sur une table stockerait dans une autre table (dans un jsonb) seulement les valeurs réellement modifiées.
J'ai pour cela créé un trigger (for each statement) et ma fonction trigger. J'essaye de trouver la méthode la moins lourde à mettre en place (sachant que potentiellement je vais devoir faire cet audit sur pas mal d'autres tables). Pour l'instant, à part comparer les colonnes 1 à 1 entre anciennes et nouvelles lignes je ne vois rien de plus rapide à écrire. L'idéal serait une façon plus générique ou dynamique de faire ça mais je bloque un peu là. Si quelqu'un a une idée je suis preneur ! Pour info la table contient des colonnes de tous types (integer, varchar, date, double , geometry). Pour les colonnes nullable je pourrais utiliser COALESCE mais le problème c'est que je ne maitrise pas forcément ce qui peut être rentrée dans certaines colonnes donc ça me semblait plus sûr avec cette méthode.

CREATE OR REPLACE FUNCTION MySchema.MyFunction() RETURNS TRIGGER AS $BODY$
DECLARE
	oldRow RECORD;
	newRow RECORD;
BEGIN
	
	-- For each row, we will compare each attribute and store in the event only ones that have changed
	FOR oldRow IN SELECT * FROM old_rows
	LOOP
		SELECT * INTO newRow FROM new_rows WHERE id = oldRow.id;
		
		-- For not null columns
		IF oldRow.col1 <> newRow.col1 THEN
			raise notice 'col1 changed';
		END IF;
		
		-- For null columns
		IF oldRow.col2 <> newRow.col2
			OR oldRow.col2 is null and newRow.col2 is not null
			OR oldRow.col2 is not null and newRow.col2 is null THEN
			raise notice 'col2 changed';
		END IF;
		
		-- Etc...
	
	END LOOP;
	
	RETURN NULL;
END;
$BODY$ LANGUAGE plpgsql;

CREATE TRIGGER MyTrigger
    AFTER UPDATE ON MyTable
    REFERENCING OLD TABLE AS old_rows NEW TABLE AS new_rows
    FOR EACH STATEMENT EXECUTE FUNCTION MySchema.MyFunction();

Merci d'avance !
Julien.

Bonjour,

J'ai une question concernant la sauvegarde à chaud avec Postgres (v9.5 et plus). Une fois que la commande pg_start_backup() a été exécutée, on peut copier tous les fichiers de l'instance nécessaires à une restauration. Sachant que pendant la sauvegarde les écritures se font toujours dans la répertoire data, comment Postgres fait-il pour que les fichiers copiés soient utilisables alors que potentiellement ils peuvent être modifiés pendant la copie ? J'ai lu que pg_start_backup force des "full page writes" (activé par défaut) jusqu'à l'exécution de pg_stop_backup(), c'est grâce à cela que lors de la restauration il peut remettre les fichiers (notamment ceux des tables par exemple) comme il faut ? En réécrivant en entier les blocks à restaurer ?

Merci.
Coridalement.

Bonjour à tous,

Je suis en train de faire une migration Oracle (11gr2) vers PostgreSQL (9.5.4) et j'ai commencé à réécrire un certain nombre de trigger en PL/pgSQL, et je rencontre un problème avec un trigger en particulier.

Supposons que j'ai un schéma A avec une table T1, et un schéma B avec une table T2 ayant la même structure que T1. T2 est une table qui va contenir les lignes supprimées de T1. J'ai donc un trigger after delete sur T1 qui fait juste un insert select OLD.* dans T2.

Le user qui exécute le delete dans T1 a uniquement des droits sur T1, et pas sur T2. Ça marchait comme ceci sous Oracle, et sous PG je suis obligé de donner au user des droits en écriture sur T2 pour que le trigger s'exécute. Y-a-t-il moyen d'empêcher ça ? Parce que je ne veux pas que le user puisse écrire directement dans T2.

Merci.
Juju.