Pages: 1
- Sujet précédent - Extension de Postgesql avec un nouveau type de données - Sujet suivant
#1 Wed 10 February 2010 15:03
- nina07
- Juste Inscrit !
- Date d'inscription: 10 Feb 2010
- Messages: 4
Extension de Postgesql avec un nouveau type de données
Bonjour,
j'aimerais Ă©tendre postgresql avec un nouveau type de donnĂ©es qui pourrait ĂȘtre utilisĂ© au sein d'une requĂȘte. D'aprĂšs ce que j'ai cru comprendre, il existe deux alternatives :
1-soit modifier le code source
2- soit créer une bibliothÚque partagée codant ce type + ses opérations. Cette bibliothÚque sera chargée à la demande.
C'est bien ça?
J'ai essayé de coder une biblio partagée (sous windows), mais je n'arrive pas à la charger dynamiquement sous windows.
Auriez vous la gentillesse de m'expliquer les Ă©tapes et les outils (peut ĂȘtre qu'il va en faloir) nĂ©cessaires pour crĂ©er mon type sous cette forme.
Merci
Hors ligne
#2 Wed 10 February 2010 16:21
Re: Extension de Postgesql avec un nouveau type de données
Bonjour,
Il me semble que Pgsql propose de créer ses propres types de données : http://docs.postgresqlfr.org/8.3/sql-createtype.html ![]()
Y.
Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !! - GeoRezo vous aide ? Aidez GeoRezo !
Hors ligne
#3 Wed 10 February 2010 18:04
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1566
Re: Extension de Postgesql avec un nouveau type de données
Bonjour,
j'aimerais Ă©tendre postgresql avec un nouveau type de donnĂ©es qui pourrait ĂȘtre utilisĂ© au sein d'une requĂȘte. D'aprĂšs ce que j'ai cru comprendre, il existe deux alternatives :
1-soit modifier le code source
2- soit créer une bibliothÚque partagée codant ce type + ses opérations. Cette bibliothÚque sera chargée à la demande.
C'est bien ça?
J'ai essayé de coder une biblio partagée (sous windows), mais je n'arrive pas à la charger dynamiquement sous windows.
Auriez vous la gentillesse de m'expliquer les Ă©tapes et les outils (peut ĂȘtre qu'il va en faloir) nĂ©cessaires pour crĂ©er mon type sous cette forme.
Merci
Bonjour,
Il me semble qu'il est egalement possible de definir un nouveau type en SQL seulement, sans ecrire de bibliotheque, pour peu que le nouveau type se compose de types de base. Des fonctions plpgsql peuvent suffire pour manipuler ce type.
A voir si un tel type peut correspondre a vos besoins:
http://www.postgresql.org/docs/8.4/static/rowtypes.html
Nicolas
Hors ligne
#4 Thu 11 February 2010 10:29
- nina07
- Juste Inscrit !
- Date d'inscription: 10 Feb 2010
- Messages: 4
Re: Extension de Postgesql avec un nouveau type de données
Merci pour les réponses.
En fait, pour ĂȘtre plus claire, mon but est d'intĂ©grer le nouveau type (un type absrait de donnĂ©e) + ses opĂ©rations de telle sorte qu'il puisse ĂȘtre utilisĂ© par n'importe quel utilisateur du SGBD au mĂȘme titre qu'un type "prĂ©dĂ©finis" (entier, point, etc...). Ainsi, un nouvel utilisateur pourra crĂ©er une nouvelle base, avec de nouvelles tables ayant comme type d'attribut (de colonne en fait) ce nouveau type.
J'ai mĂȘme une description de son domaine de valeurs.
Je ne me suis pas encore bien concentrĂ©e sur le problĂšme, mais je suppose qyue c'est le CREATE TYPE qu'il me faut. LA question est comment faire pour qu'il puisse ĂȘtre "reconnu" par n'importe quel utilisateur.
Merci encore.
Hors ligne
#5 Thu 11 February 2010 10:44
Re: Extension de Postgesql avec un nouveau type de données
Nota : ce message est envoyé en retard, il a été écrit avant la derniÚre réponse. Je poste tout de meme.
Bonjour,
j'aimerais Ă©tendre postgresql avec un nouveau type de donnĂ©es qui pourrait ĂȘtre utilisĂ© au sein d'une requĂȘte. D'aprĂšs ce que j'ai cru comprendre, il existe deux alternatives :
1-soit modifier le code source
2- soit créer une bibliothÚque partagée codant ce type + ses opérations. Cette bibliothÚque sera chargée à la demande.
Non, il ne faut certainement pas modifier le code source de PostgreSQL. Tu aurais de grandes chances de tout casser, et ton code serait inmaintenable avec les nouvelles versions.
La bonne voie si on en arrive à mettre les mains dans les couches bas niveau (ie le code C), est de créer des extensions. C'est ta solution 2, et il faut de la motivation, un bon niveau de C, du temps et des connaissances du fonctionnement interne de PostgreSQL pour se lancer la dedans. On en arrive la quand on a des contraintes ou des besoins forts, il y a d'autres solutions plus simples avant (cf ci dessous).
J'ai essayé de coder une biblio partagée (sous windows), mais je n'arrive pas à la charger dynamiquement sous windows.
Auriez vous la gentillesse de m'expliquer les Ă©tapes et les outils (peut ĂȘtre qu'il va en faloir) nĂ©cessaires pour crĂ©er mon type sous cette forme.
A noter qu'en environnement windows c'est encore plus compliqué : le passage par le compilateur MS est souvent scabreux (et tarifé), et l'utilisation de MinGW pour profiter de GCC nécessite la mise en place complexe d'un environnement de développement.
Il me semble qu'il est egalement possible de definir un nouveau type en SQL seulement, sans ecrire de bibliotheque, pour peu que le nouveau type se compose de types de base. Des fonctions plpgsql peuvent suffire pour manipuler ce type.
A voir si un tel type peut correspondre a vos besoins:
http://www.postgresql.org/docs/8.4/static/rowtypes.html
Effectivement c'est la piste la plus simple et la plus efficace (en terme de ratio effort / rĂ©sultat, pas performances). PostgreSQL permet bien de dĂ©finir ses propres types, et il en crĂ©e mĂȘme un pour chaque table qui est créée dans la base.
Ensuite il est assez facile de coder des fonctions en PLPgSQL pour faire des actions sur ces types, incluant des requetes SQL et en utilisant les fonctions SQL et PLPgSQL déjà existantes dans PostgreSQL.
Voir :
http://docs.postgresql.fr/8.4/server-programming.html
Ăa suffit dans de nombreux cas.
Maintenant, pour savoir quelle est la solution qui correspond le mieux, il faudrait avoir une description du besoin précis.
Quelques contraintes qui peuvent faire qu'on doive passer Ă de la programmation par extension :
* performance : on ne battra pas le C pour cela (mais on fera d'abord de l'optimisation algorithmique)
* Utilisation de bibliothĂšques externes
* Indexation poussée : certains types de données nécessitent une indexation particuliÚre. Par exemple les données SIG qui sont des géométries en deux dimension.
* Types de données complexes : ceux qui ne peuvent pas etre représentés par une composition de types simples de PostgreSQL (ex : des images rasters).
* Exercice d'école (ça peut arriver ![]()
A moins que tu n'aies certaines ou toutes ces contraintes, je commencerais à ta place par jeter un oeil sur la programmation coté serveur avec du plpgsql.
Hors ligne
#6 Thu 11 February 2010 11:09
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1566
Re: Extension de Postgesql avec un nouveau type de données
Merci pour les réponses.
En fait, pour ĂȘtre plus claire, mon but est d'intĂ©grer le nouveau type (un type absrait de donnĂ©e) + ses opĂ©rations de telle sorte qu'il puisse ĂȘtre utilisĂ© par n'importe quel utilisateur du SGBD au mĂȘme titre qu'un type "prĂ©dĂ©finis" (entier, point, etc...). Ainsi, un nouvel utilisateur pourra crĂ©er une nouvelle base, avec de nouvelles tables ayant comme type d'attribut (de colonne en fait) ce nouveau type.
J'ai mĂȘme une description de son domaine de valeurs.
Je ne me suis pas encore bien concentrĂ©e sur le problĂšme, mais je suppose qyue c'est le CREATE TYPE qu'il me faut. LA question est comment faire pour qu'il puisse ĂȘtre "reconnu" par n'importe quel utilisateur.
Merci encore.
Le type, crée par un administrateur, sera disponible pour les autres utilisateurs (normaux).
Voici un petit test effectué:
Connecté en tant qu'admin Postgresql:
create type mytype as (nom text, prenom text);
create table toto (id int, nom_complet mytype);
insert into toto (id, nom_complet) values (1, '("nico", "ribo")');
postgis=# select id, (nom_complet).nom, (nom_complet).prenom from toto;
id | nom | prenom
----+------+--------
1 | nico | ribo
(1 ligne)
grant select on toto to test;
Puis connexion en tant que "test", qui est un utilisateur normal:
je peux faire :
select id, (nom_complet).nom, (nom_complet).prenom from toto;
Comme le dit Vincent, cet exemple est basique en ce sens qu'il ne cree en fait qu'une nouvelle "table", mytype, qui est une composition de types simples de postgresql.
Dans ce cas, des fonctions plpgsql peuvent egalement suffire pour manipuler ce type.
Si le type à créer est plus complexe et demande des traitements particuliers (comme le type "geometry" ajouté par Postgis), alors, des methodes d'acces en C ou Python sont necessaires.
Postgis doit etre une bonne source d'exemples pour voir comment ajouter un type complexe dans PG.
Nicolas
Hors ligne
#7 Thu 11 February 2010 14:19
- nina07
- Juste Inscrit !
- Date d'inscription: 10 Feb 2010
- Messages: 4
Re: Extension de Postgesql avec un nouveau type de données
Merci Nicolas, Yves et Vincent pour ces réponses constructives.
Effectivement, Nicolas, mon type nécessite des traitements assez complexe et il est en plus de "nature" spatiale. Je comptais consulter Postgis à une étape ultérieure mais je crois que le faire à ce stade est une bonne idée!
Merci encore.
Hors ligne
#8 Thu 11 February 2010 15:22
Re: Extension de Postgesql avec un nouveau type de données
Merci Nicolas, Yves et Vincent pour ces réponses constructives.
Effectivement, Nicolas, mon type nécessite des traitements assez complexe et il est en plus de "nature" spatiale. Je comptais consulter Postgis à une étape ultérieure mais je crois que le faire à ce stade est une bonne idée!
J'en rajoute une couche : la plupart du temps les demandes un peu vagues sur des types de donnĂ©es spĂ©cifiques cachent en fait une mauvaise modĂ©lisation du problĂšme. Du genre : "je n'arrive pas bien Ă stocker des tableaux dans ma base". C'est souvent une mauvaise approche, car on perd quasiment systĂ©matiquement les avantages d'utiliser une base de donnĂ©es relationnelle : indexation, jointures, requĂȘtage SQL⊠Repenser la modĂ©lisation permet en gĂ©nĂ©ral de rĂ©soudre simplement ce qui paraissait impossible auparavant.
Dans le fond je pense que ta problématique est largement traitable par les fonctionnalités classiques de PostgreSQL, avec PostGIS pour le coté spatial, et du code plpgsql pour les traitements.
Je t'invite donc Ă nous donner le fond du problĂšme (ce que tu veux stocker, et quelles actions tu veux effectuer dessus) pour que l'on en ait le coeur net ![]()
vincent
Dernière modification par vincentp (Thu 11 February 2010 17:15)
Hors ligne
#9 Thu 11 February 2010 16:18
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3235
- Site web
Re: Extension de Postgesql avec un nouveau type de données
Bonjour,
+1 avec vincentp, j'ajouterais en plus "pouvez vous nous prĂ©ciser le contexte d'utilisation est-ce une attaque brute uniquement base de donnĂ©e oĂč y a-t-il une interface programmĂ©e ?" Car lĂ aussi il est possible d'avoir des objets complexes dans la couche mĂ©tier reprĂ©sentĂ©s par des type "simples" dans la base de donnĂ©e.
A+
Christophe
L'avantage d'ĂȘtre une Ăźle c'est d'ĂȘtre une terre topologiquement close
Hors ligne
#10 Fri 02 April 2010 16:39
- nina07
- Juste Inscrit !
- Date d'inscription: 10 Feb 2010
- Messages: 4
Re: Extension de Postgesql avec un nouveau type de données
Re-Bonjour,
En fait le type que je dois implémenter doit :
- Etendre le systĂšme de type de Postgresql/PostGIS
- Etre un Type abstrait de donnĂ©e, ceci implique que ses diffĂ©rentes composantes doivent ĂȘtre encapsulĂ©es et ne doivent ĂȘtre accessible qu'Ă travers les opĂ©rations du type
- est de nature spatio-temporelle (encapsule des Ă©lĂ©ments eux mĂȘmes composĂ©s de donnĂ©es spatiales et temporelles)
Doit il pour cela ĂȘtre implĂ©mentĂ© comme
- un type de base et donc en lgge C (pour pouvoir étendre le systÚme de type et garantir aussi l'encapsulation)?
- Un type composite peut faire l'affaire?
Dans le cas d'une dĂ©finition C (typdef), toutes les fonctions sur le type doivent aussi ĂȘtre implĂ©mentĂ©es en C ou est ce qu'elles peuvent ĂȘtre dĂ©finis avec PLPgSQL?
Merci
Hors ligne
Pages: 1
- Sujet précédent - Extension de Postgesql avec un nouveau type de données - Sujet suivant

