Vous n'êtes pas identifié(e).

#1 Re : Général » Générer un OID dans un INSERT » 27/01/2011 10:49:54

Marc Cousin a écrit :

Oui, sans souci, ça marchera très bien…

Désolé, j'aurais juré qu'elle était dans le module crypto, avec les autres smile

Y a pas de souci et je suis mal placé pour vous faire le leçon quand même lol²
Je vais essayer ça
Merci

#2 Re : Général » Générer un OID dans un INSERT » 27/01/2011 10:43:47

gleu a écrit :

Marc, ta journée a été apparemment chargée donc ne m'en veut pas si je te contredis. La fonction md5 existe bien en 7.4 (et sur les versions ultérieures aussi) :

b1=# select md5('pasdebol'), version();
               md5                |                                                 version                                                  
----------------------------------+----------------------------------------------------------------------------------------------------------
 5b8cf067ebc1a5a60362590efc4a1283 | PostgreSQL 7.4.30 on x86_64-unknown-linux-gnu, compiled by GCC gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
(1 row)

Beurk, beurk, ça fait un siècle que je n'avais pas utilisé une 7.4. On dirait un vieux DOS tout pourri (par rapport à une 9.0 bien sûr smile ).

Bonjour,
Ah cela me rassure car je lisais le contraire
du coup ma requête est-elle correcte comme cela ?

INSERT INTO table1 (champ1,champ2,champ3MD5)
SELECT champ11, champ22, MD5(champ11)
FROM table2;

suffit-il d'appeler la fonction MD5 comme je l'ai fait ?

Merci à vous

#3 Re : Général » Générer un OID dans un INSERT » 26/01/2011 16:21:35

Marc Cousin a écrit :

INSERT INTO table1 (champ1,champ2,champ3MD5)
SELECT champ11, champ22, MD5(champ11)
FROM table2

Jamais vu ça. Ça ne veut pas dire que ça n'existe pas, mais j'en doute smile

Pour pouvoir faire du md5, déjà, il va vous falloir pgcrypto, qui est un module contrib.

Ensuite, vous pourrez utiliser des fonctions comme md5(). Mais ça restera des fonctions, auxquelles il faudra passer des paramètres.

http://docs.postgresql.fr/9.0/pgcrypto.html

C'est la forme du INSERT qui vous chagrine ou la fonction MD5 en plein milieu ?
Merci à vous en tout cas

#4 Re : Général » Générer un OID dans un INSERT » 26/01/2011 15:13:27

Marc Cousin a écrit :

Quand vous faites l'insertion, si la table est WITH OIDS, la base génère d'elle même un OID pour chaque enregistrement. Par contre, si vous voulez avoir cet OID, vous serez obligé de faire un SELECT ensuite. Par ailleurs, vous ne le voyez pas par «select *» parce que c'est un champ caché. Il faut préciser la colonne oid explicitement dans le select.

Ok ça je crois avoir saisi.

Je ne vois pas le rapport avec les MD5. MD5, c'est un algorithme de hachage. On peut stocker un hash md5 dans un champ, mais c'est à vous de le faire (ou mettre un trigger qui le calcule pour vous…)

Je précise ma question : comme l'OID, je cherche à le générer automatiquement.
J'ai cru voir qu'on pouvait faire ceci :

INSERT INTO table1 (champ1,champ2,champ3MD5)
SELECT champ11, champ22, MD5(champ11)
FROM table2

Est-ce correct ?

#5 Re : Général » Générer un OID dans un INSERT » 26/01/2011 12:34:47

Marc Cousin a écrit :

Ah. En 7.4.17, il n'y a pas de façon simple de récupérer le résultat de l'insertion. Vous serez obligé de refaire un SELECT après l'insert pour en récupérer le résultat.

Au passage, cette version n'est pas du tout conseillée en production. La branche 7.4 n'est plus maintenue. Et la dernière 7.4 est la 7.4.30.

J'ai l'impression d'avoir du bol moi !!!!!
Bon si je résume je ne peux alors lors de l'insertion générer un OID ?
N'est-ce-pas le SGBD qui peut le faire si je ne le mentionne pas dans le INSERT ?

Je complète ma réflexion : mon applicatif PHP fait les insert mais ma page Web ne donne pas cet OID donc c'est bien le SGBD qui se charge de le générer, non ?
Excusez mon ignorance en la matière....

Est-ce le même souci pour un champ dans lequel je veux générer du MD5 ?

Merci pour vos réponses

#6 Re : Général » Générer un OID dans un INSERT » 26/01/2011 12:21:18

Marc Cousin a écrit :

select version();

Je suis en 7.4.17 et j'utilise pgAdmin en version 1.10.3

#7 Re : Général » Générer un OID dans un INSERT » 26/01/2011 12:03:57

Marc Cousin a écrit :

Ok. La table est en WITH OIDS ? Quelle est la version du moteur ?

Oui les tables sont avec WITH OIDS.
Le moteur = La version de POSTGRES ?
SI oui comment fais-je pour l'obtenir ?

Merci

#8 Re : Général » Générer un OID dans un INSERT » 26/01/2011 11:54:02

Marc Cousin a écrit :

Bonjour,

Plutôt que de répondre tout de suite à votre question: pourquoi voulez vous un OID ? Leur utilisation est fortement déconseillée.

Bonjour et merci

Oui je sais j'ai lu ça
Mais je suis en reprise de projet et de bases de données, et je n'ai pas trop le choix malheureusement
Et en plus, il existe un sérial dans toutes les tables....

Mais je suis obligé.

#9 Général » Générer un OID dans un INSERT » 26/01/2011 11:36:40

iviewclear
Réponses : 18

Bonjour

Est-il possible de générer un OID en même temps que l'on fait un INSERT dans une table contenant déjà des enregistrements ?

Merci

#10 Re : Général » PostGres et le type de données geometry » 19/07/2010 16:32:43

Marc Cousin a écrit :

Cela retournera la version. Mais ne vérifiera pas que tout est cohérent.

Oui merci de cette précision
Je pense qu'il va falloir recommencer l'installation pour être sur

Est-ce une chose aisée à entreprendre ou faut-il avoir des connaissances particulières ?

Merci en tout cas de votre aide précieuse

#11 Re : Général » PostGres et le type de données geometry » 19/07/2010 16:17:29

Marc Cousin a écrit :

À ma connaissance il n'y a pas de 'méthode' pour vérifier à posteriori que l'installation de postgis a été correctement faite. La vérification de la présence des fonctions en elle même ne constituera pas une assurance. Si à l'heure actuelle des fonctions vous manquent, comme addgeometrycolumn, c'est que postgis est mal installé. Il ne vous reste plus qu'à le réinstaller correctement.

Par ailleurs, on me dit de taper cette instruction-là pour vérifier l'installation de PostGIS

SELECT PostGIS_Version();

En tout cas merci

#12 Re : Général » PostGres et le type de données geometry » 19/07/2010 15:47:06

Marc Cousin a écrit :

Si vous avez un type geometry déclaré sur un des deux serveurs, c'est que PostGIS a été installé sur ce serveur. Il n'a probablement tout simplement pas été installé sur le second serveur. Installer juste quelques procédures stockées ne sera pas suffisant, car il s'appuie sur des librairies qui doivent aussi avoir été installées sur le système. Essayez de savoir si PostGIS a effectivement été installé, et si oui, obtenez la procédure et suivez la sur le second serveur.

Merci de cette réponse
Au risque d'abuser, quel est le moyen le plus simple de vérifier la bonne installation quand on sait que je n'ai accès qu'à la partie Data sur le serveur par l'intermédiare phpPGAdmin.
J'ai cru lire quelque part qu'un début de réponse était le nombre de fonctions présentes côté serveur cible, non ?

Et encore merci

#13 Général » PostGres et le type de données geometry » 19/07/2010 15:31:16

iviewclear
Réponses : 7

Bonjour,

J'ai deux serveurs distincts.
Sur chacun d'eux, j'ai une base PostGres avec évidemment des tables de données
il s'avère que je suis confronté à un souci : dans mon serveur cible (celui qui doit être une copie parfaite du serveur source), il me manque une dizaine de tables
Coïncidence, ces tables contiennent au moins 1 champ de type "geometry", type de données non reconnu dans mon serveur cible.

A force de chercher, j'ai cru comprendre qu'un ensemble de fonctions spécifiques se "chargeaient" de "créer" ce type de données.
Mais cela dépasse il faut bien le dire mes compétences !!!!

Ainsi, j'ai une fonction <b>addgeometrycolumn (character varying, character varying, character varying, character varying, integer, character varying, integer)</b> dont voici le contenu :

-- Function: addgeometrycolumn(character varying, character varying, character varying, character varying, integer, character varying, integer)
 
-- DROP FUNCTION addgeometrycolumn(character varying, character varying, character varying, character varying, integer, character varying, integer);
 
CREATE OR REPLACE FUNCTION addgeometrycolumn(character varying, character varying, character varying, character varying, integer, character varying, integer)
  RETURNS text AS
'
DECLARE
	catalog_name alias for $1;
	schema_name alias for $2;
	table_name alias for $3;
	column_name alias for $4;
	new_srid alias for $5;
	new_type alias for $6;
	new_dim alias for $7;
	rec RECORD;
	schema_ok bool;
	real_schema name;
 
BEGIN
 
	IF ( not ( (new_type =''GEOMETRY'') or
		   (new_type =''GEOMETRYCOLLECTION'') or
		   (new_type =''POINT'') or 
		   (new_type =''MULTIPOINT'') or
		   (new_type =''POLYGON'') or
		   (new_type =''MULTIPOLYGON'') or
		   (new_type =''LINESTRING'') or
		   (new_type =''MULTILINESTRING'') or
		   (new_type =''GEOMETRYCOLLECTIONM'') or
		   (new_type =''POINTM'') or 
		   (new_type =''MULTIPOINTM'') or
		   (new_type =''POLYGONM'') or
		   (new_type =''MULTIPOLYGONM'') or
		   (new_type =''LINESTRINGM'') or
		   (new_type =''MULTILINESTRINGM'')) )
	THEN
		RAISE EXCEPTION ''Invalid type name - valid ones are: 
			GEOMETRY, GEOMETRYCOLLECTION, POINT, 
			MULTIPOINT, POLYGON, MULTIPOLYGON, 
			LINESTRING, MULTILINESTRING,
			GEOMETRYCOLLECTIONM, POINTM, 
			MULTIPOINTM, POLYGONM, MULTIPOLYGONM, 
			LINESTRINGM, or MULTILINESTRINGM '';
		return ''fail'';
	END IF;
 
	IF ( (new_dim >4) or (new_dim <0) ) THEN
		RAISE EXCEPTION ''invalid dimension'';
		return ''fail'';
	END IF;
 
	IF ( (new_type LIKE ''%M'') and (new_dim!=3) ) THEN
 
		RAISE EXCEPTION ''TypeM needs 3 dimensions'';
		return ''fail'';
	END IF;
 
	IF ( schema_name != '''' ) THEN
		schema_ok = ''f'';
		FOR rec IN SELECT nspname FROM pg_namespace WHERE text(nspname) = schema_name LOOP
			schema_ok := ''t'';
		END LOOP;
 
		if ( schema_ok <> ''t'' ) THEN
			RAISE NOTICE ''Invalid schema name - using current_schema()'';
			SELECT current_schema() into real_schema;
		ELSE
			real_schema = schema_name;
		END IF;
 
	ELSE
		SELECT current_schema() into real_schema;
	END IF;
 
 
	-- Add geometry column
 
	EXECUTE ''ALTER TABLE '' ||
		quote_ident(real_schema) || ''.'' || quote_ident(table_name)
		|| '' ADD COLUMN '' || quote_ident(column_name) || 
		'' geometry '';
 
 
	-- Delete stale record in geometry_column (if any)
 
	EXECUTE ''DELETE FROM geometry_columns WHERE
		f_table_catalog = '' || quote_literal('''') || 
		'' AND f_table_schema = '' ||
		quote_literal(real_schema) || 
		'' AND f_table_name = '' || quote_literal(table_name) ||
		'' AND f_geometry_column = '' || quote_literal(column_name);
 
 
	-- Add record in geometry_column 
 
	EXECUTE ''INSERT INTO geometry_columns VALUES ('' ||
		quote_literal('''') || '','' ||
		quote_literal(real_schema) || '','' ||
		quote_literal(table_name) || '','' ||
		quote_literal(column_name) || '','' ||
		new_dim || '','' || new_srid || '','' ||
		quote_literal(new_type) || '')'';
 
	-- Add table checks
 
	EXECUTE ''ALTER TABLE '' || 
		quote_ident(real_schema) || ''.'' || quote_ident(table_name)
		|| '' ADD CONSTRAINT '' 
		|| quote_ident(''enforce_srid_'' || column_name)
		|| '' CHECK (SRID('' || quote_ident(column_name) ||
		'') = '' || new_srid || '')'' ;
 
	EXECUTE ''ALTER TABLE '' || 
		quote_ident(real_schema) || ''.'' || quote_ident(table_name)
		|| '' ADD CONSTRAINT ''
		|| quote_ident(''enforce_dims_'' || column_name)
		|| '' CHECK (ndims('' || quote_ident(column_name) ||
		'') = '' || new_dim || '')'' ;
 
	IF (not(new_type = ''GEOMETRY'')) THEN
		EXECUTE ''ALTER TABLE '' || 
		quote_ident(real_schema) || ''.'' || quote_ident(table_name)
		|| '' ADD CONSTRAINT ''
		|| quote_ident(''enforce_geotype_'' || column_name)
		|| '' CHECK (geometrytype('' ||
		quote_ident(column_name) || '')='' ||
		quote_literal(new_type) || '' OR ('' ||
		quote_ident(column_name) || '') is null)'';
	END IF;
 
	return 
		real_schema || ''.'' || 
		table_name || ''.'' || column_name ||
		'' SRID:'' || new_srid ||
		'' TYPE:'' || new_type || 
		'' DIMS:'' || new_dim || chr(10) || '' ''; 
END;
'
  LANGUAGE 'plpgsql' VOLATILE STRICT;

Quelqu'un peut-il me confirmer ou pas que ce script fait bien en sorte que ce type de données soit bien reconnu par la base en cours ?

Si oui découle alors mon autre question :
Comment faire dans mon serveur cible (là ou je ne dispose pas de toutes les tables) pour que ce type de données soit bien reconnu avec la fonction qui est bien présente aussi sur ce serveur ?

Car il évidemment si je prends un script me permettant de créer une table dont un des champs est de ce type, cela ne fonctionne pas !!!!!
Un peu d'aide sur la compréhension de ce souci serait la bienvenue

En attendant, bonne journée à tous

Pied de page des forums

Propulsé par FluxBB