Vous n'êtes pas identifié(e).
Pages : 1
Oui, sans souci, ça marchera très bien…
Désolé, j'aurais juré qu'elle était dans le module crypto, avec les autres
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
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 ).
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
INSERT INTO table1 (champ1,champ2,champ3MD5)
SELECT champ11, champ22, MD5(champ11)
FROM table2Jamais vu ça. Ça ne veut pas dire que ça n'existe pas, mais j'en doute
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.
C'est la forme du INSERT qui vous chagrine ou la fonction MD5 en plein milieu ?
Merci à vous en tout cas
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 ?
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
select version();
Je suis en 7.4.17 et j'utilise pgAdmin en version 1.10.3
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
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é.
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
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
À 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
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
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
Pages : 1