Re: Gestion des adresses URL avec parse_url

Bonjour à tous,

Je viens ici demander quelques feedbacks à propos d'une fonctionnalité
que je suis en train de développer.

Je suis en train de développer une série de fonctions permettant de
manipuler des adresses URL directement dans la base de données. Pour le
moment, j'ai fait le plus dur avec ces fonctions:
- url *parse_url_exec (char * url_str) - utilisée par les deux
fonctions suivantes
- Datum parse_url_key (PG_FUNCTION_ARGS) qui prend deux arguments:
- text: L'adresse URL
- text: Quoi récupérer dans cette liste: scheme (http, https, ftp,
etc...), user (le nom d'utilisateur quand il y a), pass (mot de passe
quand il y a), host (nom de domaine), path, query (requête - i.e. après
"?"), fragment (quel endroit de la page - i.e. après "#")
- Datum parse_url_record (PG_FUNCTION_ARGS) qui prend un seul argument
(text), l'adresse URL. Elle retourne un tuple de char*. i.e. un record.

Pour simplifier la vie pour la récupération du record, j'ai fait un type
SQL "url" comme ceci:
------------------------------------------------------------
CREATE TYPE url AS ("scheme" text, "user" text, "pass" text, "host"
text, "port" integer, "path" text, "query" text, "fragment" text);
------------------------------------------------------------

Les deux fonctions C sont définies comme ça:
------------------------------------------------------------
CREATE FUNCTION parse_url(text, text) RETURNS text AS 'parse_url.so',
'parse_url_key' LANGUAGE C STRICT;
------------------------------------------------------------
CREATE FUNCTION parse_url (text) RETURNS url AS 'parse_url.so',
'parse_url_record' LANGUAGE C STRICT;
------------------------------------------------------------

Vous pouvez télécharger le code dans une archive contenant le fichier .c
et .h, le Makefile ainsi que un fichier SQL qui contient ce que je vous
ai présenté ci-dessus.
http://www.d-sites.com/wp-content/uploads/2009/10/parse_url.tar.gz

En toute logique, je vais continuer pour créer un "vrai" type de donnée
"url" utilisable en tant que champ SQL, qui permettra ensuite de bien
mieux gérer les adresses URL.

Je souhaites avoir des retours de votre part avant d'en faire part à la
mailing "pgsql-hackers@" ainsi qu'avant publication sur mon blog.

Note: cf en bas du mail pour les résultats de quelques requêtes sur ma
base de test en 8.4.1.

Cordialement,
Samuel ROZE.
http://wwW.d-sites.com

------------------------------------------------------------
Sur une base de données PostgreSQL 8.4.1, avec le même code que dans
l'archive ci-dessus, compilé avec le même Makefile, après application
des 3 requêtes de création et type et de fonction, voilà le résultat
obtenu:

postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'host');
parse_url
-----------------
www.d-sites.com
(1 row)

postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'scheme');
parse_url
-----------
http
(1 row)

postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'port');
parse_url
-----------

(1 row)

postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'port') IS NULL;
?column?
----------
t
(1 row)

postgres=# SELECT * FROM parse_url('http://www.d-sites.com/test.php?query=info');
scheme | user | pass | host | port | path | query | fragment
--------+------+------+-----------------+------+-----------+------------+----------
http | | | www.d-sites.com | | /test.php | query=info |
(1 row)

postgres=# SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968');
scheme | user | pass | host | port | path | query | fragment
--------+------+------+--------------------+------+-------------------------------+-------+----------
http | | | www.postgresql.org | | /docs/8.4/static/xfunc-c.html | | AEN44968
(1 row)

postgres=# EXPLAIN ANALYSE SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968');
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Function Scan on parse_url (cost=0.00..0.01 rows=1 width=228) (actual time=0.036..0.039 rows=1 loops=1)
Total runtime: 0.087 ms
(2 rows)

postgres=# EXPLAIN ANALYSE SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968', 'path');
QUERY PLAN
---------------------------------------------------------------------------------------------------------
Function Scan on parse_url (cost=0.00..0.01 rows=1 width=32) (actual time=0.026..0.029 rows=1 loops=1)
Total runtime: 0.070 ms
(2 rows)

Samuel ROZE a écrit :
> Bonjour à tous,
>
> Je viens ici demander quelques feedbacks à propos d'une fonctionnalité
> que je suis en train de développer.
>
> Je suis en train de développer une série de fonctions permettant de
> manipuler des adresses URL directement dans la base de données. Pour le
> moment, j'ai fait le plus dur avec ces fonctions:
> - url *parse_url_exec (char * url_str) - utilisée par les deux
> fonctions suivantes
> - Datum parse_url_key (PG_FUNCTION_ARGS) qui prend deux arguments:
> - text: L'adresse URL
> - text: Quoi récupérer dans cette liste: scheme (http, https, ftp,
> etc...), user (le nom d'utilisateur quand il y a), pass (mot de passe
> quand il y a), host (nom de domaine), path, query (requête - i.e. après
> "?"), fragment (quel endroit de la page - i.e. après "#")
> - Datum parse_url_record (PG_FUNCTION_ARGS) qui prend un seul argument
> (text), l'adresse URL. Elle retourne un tuple de char*. i.e. un record.
>
> Pour simplifier la vie pour la récupération du record, j'ai fait un type
> SQL "url" comme ceci:
> ------------------------------------------------------------
> CREATE TYPE url AS ("scheme" text, "user" text, "pass" text, "host"
> text, "port" integer, "path" text, "query" text, "fragment" text);
> ------------------------------------------------------------
>
> Les deux fonctions C sont définies comme ça:
> ------------------------------------------------------------
> CREATE FUNCTION parse_url(text, text) RETURNS text AS 'parse_url.so',
> 'parse_url_key' LANGUAGE C STRICT;
> ------------------------------------------------------------
> CREATE FUNCTION parse_url (text) RETURNS url AS 'parse_url.so',
> 'parse_url_record' LANGUAGE C STRICT;
> ------------------------------------------------------------
>
> Vous pouvez télécharger le code dans une archive contenant le fichier .c
> et .h, le Makefile ainsi que un fichier SQL qui contient ce que je vous
> ai présenté ci-dessus.
> http://www.d-sites.com/wp-content/uploads/2009/10/parse_url.tar.gz
>
> En toute logique, je vais continuer pour créer un "vrai" type de donnée
> "url" utilisable en tant que champ SQL, qui permettra ensuite de bien
> mieux gérer les adresses URL.
>
> Je souhaites avoir des retours de votre part avant d'en faire part à la
> mailing "pgsql-hackers@" ainsi qu'avant publication sur mon blog.
>

Salut !

Je viens de tester avec une 8.3.8 et j'ai l'erreur suivante :

test=# \i /tmp/parse_url.sql
CREATE TYPE
psql:/tmp/parse_url.sql:3: ERREUR: n'a pas pu charger la bibliothèque «
/usr/lib/postgresql/8.3/lib/parse_url.so » :
/usr/lib/postgresql/8.3/lib/parse_url.so: undefined symbol:
TextDatumGetCString
psql:/tmp/parse_url.sql:4: ERREUR: n'a pas pu charger la bibliothèque «
/usr/lib/postgresql/8.3/lib/parse_url.so » :
/usr/lib/postgresql/8.3/lib/parse_url.so: undefined symbol:
TextDatumGetCString

J'ai peut-être mal compris qqchose ou bien ton code n'est compatible
qu'avec la version 8.4 ?

Au passage, je pense que tu devrais déclarer les fonctions parse_url
comme IMMUTABLE, puisqu'elles renvoient toujours les même résultats si
on leur passe les même arguments. Plus d'info :

http://docs.postgresqlfr.org/8.4/xfunc-volatility.html

En tout cas, bravo pour cette initiative !

--
damien clochard
http://dalibo.org | http://dalibo.com

Le jeudi 22 octobre 2009 10:38:42, damien clochard a écrit :
> Samuel ROZE a écrit :
> >
> > Vous pouvez télécharger le code dans une archive contenant le fichier .c
> > et .h, le Makefile ainsi que un fichier SQL qui contient ce que je vous
> > ai présenté ci-dessus.
> > http://www.d-sites.com/wp-content/uploads/2009/10/parse_url.tar.gz
> >
> > En toute logique, je vais continuer pour créer un "vrai" type de donnée
> > "url" utilisable en tant que champ SQL, qui permettra ensuite de bien
> > mieux gérer les adresses URL.
> >
> > Je souhaites avoir des retours de votre part avant d'en faire part à la
> > mailing "pgsql-hackers@" ainsi qu'avant publication sur mon blog.
>
> Salut !
>
> Je viens de tester avec une 8.3.8 et j'ai l'erreur suivante :
>
> test=# \i /tmp/parse_url.sql
> CREATE TYPE
> psql:/tmp/parse_url.sql:3: ERREUR: n'a pas pu charger la bibliothèque «
> /usr/lib/postgresql/8.3/lib/parse_url.so » :
> /usr/lib/postgresql/8.3/lib/parse_url.so: undefined symbol:
> TextDatumGetCString
> psql:/tmp/parse_url.sql:4: ERREUR: n'a pas pu charger la bibliothèque «
> /usr/lib/postgresql/8.3/lib/parse_url.so » :
> /usr/lib/postgresql/8.3/lib/parse_url.so: undefined symbol:
> TextDatumGetCString
>
> J'ai peut-être mal compris qqchose ou bien ton code n'est compatible
> qu'avec la version 8.4 ?

C'est bien possible, il y a des évolutions de code entre 8.3 et 8.4.
J'ai le soucis avec pgfincore.

>
> Au passage, je pense que tu devrais déclarer les fonctions parse_url
> comme IMMUTABLE, puisqu'elles renvoient toujours les même résultats si
> on leur passe les même arguments. Plus d'info :
>
> http://docs.postgresqlfr.org/8.4/xfunc-volatility.html
>
> En tout cas, bravo pour cette initiative !
>
>
> --
> damien clochard
> http://dalibo.org | http://dalibo.com
>

--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

On Wed, Oct 21, 2009 at 10:00:26PM +0200,
Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> wrote
a message of 115 lines which said:

> Je suis en train de développer une série de fonctions permettant de
> manipuler des adresses URL directement dans la base de données.

Très bonne idée mais, sur la partie non-PostgreSQL, puis-je suggérer
qu'il aurait été préférable d'utiliser une bibliothèque d'analyse
d'URL existante plutôt que de reprogrammer ?

Et, pendant que je joue l'utilisateur pénible, est-il prévu de gérer
les IRI également ?

Le jeudi 22 octobre 2009 14:28:11, Stephane Bortzmeyer a écrit :
> On Wed, Oct 21, 2009 at 10:00:26PM +0200,
> Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> wrote
>
> a message of 115 lines which said:
> > Je suis en train de développer une série de fonctions permettant de
> > manipuler des adresses URL directement dans la base de données.
>
> Très bonne idée mais, sur la partie non-PostgreSQL, puis-je suggérer
> qu'il aurait été préférable d'utiliser une bibliothèque d'analyse
> d'URL existante plutôt que de reprogrammer ?
>
> Et, pendant que je joue l'utilisateur pénible, est-il prévu de gérer
> les IRI également ?
>

non, il n'a pas un mail @nic :-D

(je suis d'accord sur l'ensemble des remarques ceci dit, une partie du code
est peut-etre deja présente au niveau de tsearch qui sait détecter les urls,
peut-etre une piste de travail aussi)

--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

Bonjour,

Le problème sous 8.3 c'est que TextDatumGetCString n'est en éffet pas
défini dans "utils/builtins.h" !
Peut-être il y a-t-il d'autre méthodes pour y accèder ?

Mettre:
#define CStringGetTextP(c) DatumGetTextP(DirectFunctionCall1(textin,
CStringGetDatum(c)))

Le suffit pas il me semble car "textin" n'est probablement pas déclaré
dans n'importe quelle librairie de /include/...

Samuel.

Le 22 octobre 2009 10:38, damien clochard <damien(at)dalibo(dot)info> a écrit :
> Samuel ROZE a écrit :
>> Bonjour à tous,
>>
>> Je viens ici demander quelques feedbacks à propos d'une fonctionnalité
>> que je suis en train de développer.
>>
>> Je suis en train de développer une série de fonctions permettant de
>> manipuler des adresses URL directement dans la base de données. Pour le
>> moment, j'ai fait le plus dur avec ces fonctions:
>> - url *parse_url_exec (char * url_str) - utilisée par les deux
>> fonctions suivantes
>> - Datum parse_url_key (PG_FUNCTION_ARGS) qui prend deux arguments:
>> - text: L'adresse URL
>> - text: Quoi récupérer dans cette liste: scheme (http, https, ftp,
>> etc...), user (le nom d'utilisateur quand il y a), pass (mot de passe
>> quand il y a), host (nom de domaine), path, query (requête - i.e. après
>> "?"), fragment (quel endroit de la page - i.e. après "#")
>> - Datum parse_url_record (PG_FUNCTION_ARGS) qui prend un seul argument
>> (text), l'adresse URL. Elle retourne un tuple de char*. i.e. un record.
>>
>> Pour simplifier la vie pour la récupération du record, j'ai fait un type
>> SQL "url" comme ceci:
>> ------------------------------------------------------------
>> CREATE TYPE url AS ("scheme" text, "user" text, "pass" text, "host"
>> text, "port" integer, "path" text, "query" text, "fragment" text);
>> ------------------------------------------------------------
>>
>> Les deux fonctions C sont définies comme ça:
>> ------------------------------------------------------------
>> CREATE FUNCTION parse_url(text, text) RETURNS text AS 'parse_url.so',
>> 'parse_url_key' LANGUAGE C STRICT;
>> ------------------------------------------------------------
>> CREATE FUNCTION parse_url (text) RETURNS url AS 'parse_url.so',
>> 'parse_url_record' LANGUAGE C STRICT;
>> ------------------------------------------------------------
>>
>> Vous pouvez télécharger le code dans une archive contenant le fichier .c
>> et .h, le Makefile ainsi que un fichier SQL qui contient ce que je vous
>> ai présenté ci-dessus.
>> http://www.d-sites.com/wp-content/uploads/2009/10/parse_url.tar.gz
>>
>> En toute logique, je vais continuer pour créer un "vrai" type de donnée
>> "url" utilisable en tant que champ SQL, qui permettra ensuite de bien
>> mieux gérer les adresses URL.
>>
>> Je souhaites avoir des retours de votre part avant d'en faire part à la
>> mailing "pgsql-hackers@" ainsi qu'avant publication sur mon blog.
>>
>
> Salut !
>
> Je viens de tester avec une 8.3.8 et j'ai l'erreur suivante :
>
> test=# \i /tmp/parse_url.sql
> CREATE TYPE
> psql:/tmp/parse_url.sql:3: ERREUR: n'a pas pu charger la bibliothèque «
> /usr/lib/postgresql/8.3/lib/parse_url.so » :
> /usr/lib/postgresql/8.3/lib/parse_url.so: undefined symbol:
> TextDatumGetCString
> psql:/tmp/parse_url.sql:4: ERREUR: n'a pas pu charger la bibliothèque «
> /usr/lib/postgresql/8.3/lib/parse_url.so » :
> /usr/lib/postgresql/8.3/lib/parse_url.so: undefined symbol:
> TextDatumGetCString
>
> J'ai peut-être mal compris qqchose ou bien ton code n'est compatible
> qu'avec la version 8.4 ?
>
> Au passage, je pense que tu devrais déclarer les fonctions parse_url
> comme IMMUTABLE, puisqu'elles renvoient toujours les même résultats si
> on leur passe les même arguments. Plus d'info :
>
> http://docs.postgresqlfr.org/8.4/xfunc-volatility.html
>
> En tout cas, bravo pour cette initiative !
>
>
> --
> damien clochard
> http://dalibo.org | http://dalibo.com
>

Le 22 octobre 2009 14:28, Stephane Bortzmeyer <bortzmeyer(at)nic(dot)fr> a écrit :
> On Wed, Oct 21, 2009 at 10:00:26PM +0200,
> Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> wrote
> a message of 115 lines which said:
>
>> Je suis en train de développer une série de fonctions permettant de
>> manipuler des adresses URL directement dans la base de données.
>
> Très bonne idée mais, sur la partie non-PostgreSQL, puis-je suggérer
> qu'il aurait été préférable d'utiliser une bibliothèque d'analyse
> d'URL existante plutôt que de reprogrammer ?

A quelle librairie pensez-vous ?
Cependant, je n'ai pas envi d'intégrer des librairies complémentaires
car ça alourdi le code, qui n'est plus tout à fait maitrisé par une
personne de la communauté... Bref, le "support" ou plutôt le maintient
du code n'est pas top, et dans la majorité des cas, ce n'est pas
utile.

>
> Et, pendant que je joue l'utilisateur pénible, est-il prévu de gérer
> les IRI également ?

Je ne connaissait pas l'IRI ! En fait, ce qu'il "suffirait" de faire,
c'est de transformer les chaines codées en utf-8 en ASCII en à la
manière de Punycode avant de traiter l'url normalement ? Puis,
re-transformer les différents champs en utf-8 après analyse ?
( http://fr.wikipedia.org/wiki/Nom_de_domaine_internationalis%C3%A9 )

Le 22 octobre 2009 15:01, Cédric Villemain
<cedric(dot)villemain(at)dalibo(dot)com> a écrit :
> (je suis d'accord sur l'ensemble des remarques ceci dit, une partie du code
> est peut-etre deja présente au niveau de tsearch qui sait détecter les urls,
> peut-etre une piste de travail aussi)

Merci de l'info :-)
Cependant, je ne sais pas vraiment à quoi sert cette librairie, quand
est-elle appelée et quand analyse-t-elles des adresses URL ?
Permet-elle d'y récupérer des "bouts" - i.e. host, path, scheme,
etc... ?

On Thu, Oct 22, 2009 at 04:23:38PM +0200,
Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> wrote
a message of 28 lines which said:

> > Très bonne idée mais, sur la partie non-PostgreSQL, puis-je
> > suggérer qu'il aurait été préférable d'utiliser une bibliothèque
> > d'analyse d'URL existante plutôt que de reprogrammer ?
>
> A quelle librairie pensez-vous ?

Personnellement, j'utilise la bibliothèque du W3C
<http://www.w3.org/Library/src/HTParse> mais beaucoup de gens
préfèrent uriparser <http://uriparser.sourceforge.net/>

On Thu, Oct 22, 2009 at 10:38:42AM +0200,
damien clochard <damien(at)dalibo(dot)info> wrote
a message of 84 lines which said:

> /usr/lib/postgresql/8.3/lib/parse_url.so: undefined symbol:
> TextDatumGetCString
...
> J'ai peut-être mal compris qqchose ou bien ton code n'est compatible
> qu'avec la version 8.4 ?

En prime, TextDatumGetCString semble très peu documenté. À part dans
les sources, il y a un endroit où il est expliqué ?

On Thu, Oct 22, 2009 at 04:23:38PM +0200,
Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> wrote
a message of 28 lines which said:

> En fait, ce qu'il "suffirait" de faire, c'est de transformer les
> chaines codées en utf-8 en ASCII en à la manière de Punycode avant
> de traiter l'url normalement ? Puis, re-transformer les différents
> champs en utf-8 après analyse ? (
> http://fr.wikipedia.org/wiki/Nom_de_domaine_internationalis%C3%A9 )

Attention, la transformation des IRI en URI n'utilise pas Punycode
sauf pour le nom de machine. Le reste est en utf-8 (éventuellement
pourcent-échappé). Voir le RFC 3987, section 3.1.

http://www.w3.org/International/articles/idn-and-iri/

Le jeudi 22 octobre 2009 à 16:14:17, Samuel ROZE a écrit :
> Bonjour,
>
> Le problème sous 8.3 c'est que TextDatumGetCString n'est en éffet pas
> défini dans "utils/builtins.h" !
> Peut-être il y a-t-il d'autre méthodes pour y accèder ?
>
> Mettre:
> #define CStringGetTextP(c) DatumGetTextP(DirectFunctionCall1(textin,
> CStringGetDatum(c)))
>
> Le suffit pas il me semble car "textin" n'est probablement pas déclaré
> dans n'importe quelle librairie de /include/...
>

Pourquoi ne pas utiliser la définition 8.4 ? ainsi:

#ifndef TextDatumGetCString
#define TextDatumGetCString(d) text_to_cstring((text *) DatumGetPointer(d))
#endif

Avec ça, je compile en 8.3 comme en 8.4 (je suis trop fatigué pour tester sur
les autres versions). Et j'utilise ça sans problème.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> #ifndef TextDatumGetCString
> #define TextDatumGetCString(d) text_to_cstring((text *) DatumGetPointer(d))
> #endif
>
> Avec ça, je compile en 8.3 comme en 8.4 (je suis trop fatigué pour tester sur
> les autres versions). Et j'utilise ça sans problème.

Euh je croyais (de mémoire, pas vérifié) que text_to_cstring() c'était à
partir de la 8.4 seulement ?

À mon tour de partager ma recette :

text *txt = PG_GETARG_TEXT_P(0);
char *str =
DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(txt)));

Ça marche depuis 8.1, j'ai pas testé avant.
--
dim

Merci à vous deux pour ces petites méthodes bien sympathiques ! :-)

Seulement, j'ai solver le problème en créant un type utilisateur "url",
associé au type "url", maintenant "urltype" du code C...

C'est plus simple, plus logique, mieux quoi ;-)
Je vais très prochainement écrire un mail là dessus en réponse à mon
premier mail.

Merci beaucoup à tous de regarder le code et de tester, c'est très
sympa !

Cordialement,
Samuel.

Le jeudi 22 octobre 2009 à 23:43 +0200, Dimitri Fontaine a écrit :
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> > #ifndef TextDatumGetCString
> > #define TextDatumGetCString(d) text_to_cstring((text *) DatumGetPointer(d))
> > #endif
> >
> > Avec ça, je compile en 8.3 comme en 8.4 (je suis trop fatigué pour tester sur
> > les autres versions). Et j'utilise ça sans problème.
>
> Euh je croyais (de mémoire, pas vérifié) que text_to_cstring() c'était à
> partir de la 8.4 seulement ?
>
> À mon tour de partager ma recette :
>
> text *txt = PG_GETARG_TEXT_P(0);
> char *str =
> DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(txt)));
>
> Ça marche depuis 8.1, j'ai pas testé avant.

Bonjour !

Tout d'abord, merci beaucoup pour l'attention que vous porter à mon
petit projet.

J'ai grandement modifier le code source dans cette "v2", qui ne
s'appelle déjà plus "parse_url" mais "url" (même si la fonction
"parse_url" a toujours le même nom).

J'ai créer:
- Un type interne "urltype" à la place de l'ancien type "url"
- Un type SQL "url" défini par les deux fonctions suivantes:
- Une fonction "url_in" et son homologue "url_out" pour gérer le type de
donnée "url".
- Un type SQL "url_record", retourné par "parse_url(url)"

http://www.d-sites.com/wp-content/uploads/2009/10/url.tar.gz

Comme avant, il est compilable par un simple "make" et les requêtes SQL
à exécuter sont présentes dans le fichier "url.sql".

Voici quelques exemples:
postgres=# SELECT parse_url('http://www.d-sites.com/index.php?q=query&r=postgresql#p2');
parse_url
--------------------------------------------------------------
(http,,,www.d-sites.com,,/index.php,q=query&r=postgresql,p2)
(1 row)

postgres=# SELECT * FROM parse_url('http://www.d-sites.com/index.php?q=query&r=postgresql#p2');
scheme | user | pass | host | port | path | query | fragment
--------+------+------+-----------------+------+------------+----------------------+----------
http | | | www.d-sites.com | | /index.php | q=query&r=postgresql | p2
(1 row)

postgres=# SELECT parse_url('http://www.d-sites.com/index.php?q=query&r=postgresql#p2', 'query');
parse_url
----------------------
q=query&r=postgresql
(1 row)

Toujours le même chose, qu'en pensez-vous ?

Merci encore !
Cordialement,
Samuel.

Le mercredi 21 octobre 2009 à 22:00 +0200, Samuel ROZE a écrit :
> Bonjour à tous,
>
> Je viens ici demander quelques feedbacks à propos d'une fonctionnalité
> que je suis en train de développer.
>
> Je suis en train de développer une série de fonctions permettant de
> manipuler des adresses URL directement dans la base de données. Pour le
> moment, j'ai fait le plus dur avec ces fonctions:
> - url *parse_url_exec (char * url_str) - utilisée par les deux
> fonctions suivantes
> - Datum parse_url_key (PG_FUNCTION_ARGS) qui prend deux arguments:
> - text: L'adresse URL
> - text: Quoi récupérer dans cette liste: scheme (http, https, ftp,
> etc...), user (le nom d'utilisateur quand il y a), pass (mot de passe
> quand il y a), host (nom de domaine), path, query (requête - i.e. après
> "?"), fragment (quel endroit de la page - i.e. après "#")
> - Datum parse_url_record (PG_FUNCTION_ARGS) qui prend un seul argument
> (text), l'adresse URL. Elle retourne un tuple de char*. i.e. un record.
>
> Pour simplifier la vie pour la récupération du record, j'ai fait un type
> SQL "url" comme ceci:
> ------------------------------------------------------------
> CREATE TYPE url AS ("scheme" text, "user" text, "pass" text, "host"
> text, "port" integer, "path" text, "query" text, "fragment" text);
> ------------------------------------------------------------
>
> Les deux fonctions C sont définies comme ça:
> ------------------------------------------------------------
> CREATE FUNCTION parse_url(text, text) RETURNS text AS 'parse_url.so',
> 'parse_url_key' LANGUAGE C STRICT;
> ------------------------------------------------------------
> CREATE FUNCTION parse_url (text) RETURNS url AS 'parse_url.so',
> 'parse_url_record' LANGUAGE C STRICT;
> ------------------------------------------------------------
>
> Vous pouvez télécharger le code dans une archive contenant le fichier .c
> et .h, le Makefile ainsi que un fichier SQL qui contient ce que je vous
> ai présenté ci-dessus.
> http://www.d-sites.com/wp-content/uploads/2009/10/parse_url.tar.gz
>
> En toute logique, je vais continuer pour créer un "vrai" type de donnée
> "url" utilisable en tant que champ SQL, qui permettra ensuite de bien
> mieux gérer les adresses URL.
>
> Je souhaites avoir des retours de votre part avant d'en faire part à la
> mailing "pgsql-hackers@" ainsi qu'avant publication sur mon blog.
>
> Note: cf en bas du mail pour les résultats de quelques requêtes sur ma
> base de test en 8.4.1.
>
> Cordialement,
> Samuel ROZE.
> http://wwW.d-sites.com
>
> ------------------------------------------------------------
> Sur une base de données PostgreSQL 8.4.1, avec le même code que dans
> l'archive ci-dessus, compilé avec le même Makefile, après application
> des 3 requêtes de création et type et de fonction, voilà le résultat
> obtenu:
>
> postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'host');
> parse_url
> -----------------
> www.d-sites.com
> (1 row)
>
> postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'scheme');
> parse_url
> -----------
> http
> (1 row)
>
> postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'port');
> parse_url
> -----------
>
> (1 row)
>
> postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'port') IS NULL;
> ?column?
> ----------
> t
> (1 row)
>
> postgres=# SELECT * FROM parse_url('http://www.d-sites.com/test.php?query=info');
> scheme | user | pass | host | port | path | query | fragment
> --------+------+------+-----------------+------+-----------+------------+----------
> http | | | www.d-sites.com | | /test.php | query=info |
> (1 row)
>
> postgres=# SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968');
> scheme | user | pass | host | port | path | query | fragment
> --------+------+------+--------------------+------+-------------------------------+-------+----------
> http | | | www.postgresql.org | | /docs/8.4/static/xfunc-c.html | | AEN44968
> (1 row)
>
> postgres=# EXPLAIN ANALYSE SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968');
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------
> Function Scan on parse_url (cost=0.00..0.01 rows=1 width=228) (actual time=0.036..0.039 rows=1 loops=1)
> Total runtime: 0.087 ms
> (2 rows)
>
> postgres=# EXPLAIN ANALYSE SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968', 'path');
> QUERY PLAN
> ---------------------------------------------------------------------------------------------------------
> Function Scan on parse_url (cost=0.00..0.01 rows=1 width=32) (actual time=0.026..0.029 rows=1 loops=1)
> Total runtime: 0.070 ms
> (2 rows)
>

Il s'avère qu'il y a un bug lors de la création de tables avec le type
"url" que je ne voit pas comment résoudre... Pourriez-vous m'apporter
vos lumières ? :/

---------------------------------------------------------
postgres=# CREATE TABLE tests_url (
postgres(# id SERIAL,
postgres(# mon_url url,
postgres(# url_text text
postgres(# );
NOTICE: CREATE TABLE will create implicit sequence "tests_url_id_seq" for serial column "tests_url.id"
CREATE TABLE
postgres=# INSERT INTO tests_url (mon_url) VALUES ('http://www.postgresqlfr.org');
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
---------------------------------------------------------

Si en même temps j'utilise gdb et qu'après le crash je fait un
backtrace, voilà ce que j'ai:
---------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0xb7dd0b56 in memcpy () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7dd0b56 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0x00000001 in ?? ()
#2 0x080906b5 in heap_form_tuple (tupleDescriptor=0x8686020, values=0x8686228, isnull=0x86862d0 "") at heaptuple.c:757
#3 0x0819b879 in ExecCopySlotTuple (slot=0x84efa5) at execTuples.c:641
#4 0x0819b8b2 in ExecMaterializeSlot (slot=0x8685590) at execTuples.c:833
#5 0x0819156b in standard_ExecutorRun (queryDesc=0x8684fc8, direction=ForwardScanDirection, count=0) at execMain.c:1761
#6 0x08242a26 in ProcessQuery (plan=0x863f508, sourceText=0x863df10 "INSERT INTO tests_url (mon_url) VALUES ('http://www.postgresqlfr.org');",
params=<value optimized out>, dest=0x863f798, completionTag=0xbfc0a478 "") at pquery.c:196
#7 0x08242c2b in PortalRunMulti (portal=0x8682fc0, isTopLevel=<value optimized out>, dest=0x863f798, altdest=0x863f798, completionTag=0xbfc0a478 "")
at pquery.c:1269
#8 0x082433a4 in PortalRun (portal=0x8682fc0, count=2147483647, isTopLevel=-116 '\214', dest=0x863f798, altdest=0x863f798, completionTag=0xbfc0a478 "")
at pquery.c:823
#9 0x0823e1a8 in exec_simple_query (query_string=0x863df10 "INSERT INTO tests_url (mon_url) VALUES ('http://www.postgresqlfr.org');") at postgres.c:991
#10 0x0823fadf in PostgresMain (argc=4, argv=0x85cb208, username=0x85cb1d8 "postgres") at postgres.c:3614
#11 0x0821237b in ServerLoop () at postmaster.c:3447
#12 0x0821339a in PostmasterMain (argc=3, argv=0x85c71d0) at postmaster.c:1040
#13 0x081bb936 in main (argc=3, argv=0x85c71d0) at main.c:188
---------------------------------------------------------

Un problème de mémoire... Ce que je ne comprend pas c'est pourquoi ça
marche dans les autres cas et pas là.. Bizarre ! J'ai chercher
différentes variables qui auraient pu être non-initialisées mais je ne
voit pas...

Merci d'avance !
Samuel.

Le vendredi 23 octobre 2009 à 00:59 +0200, Samuel ROZE a écrit :
> Bonjour !
>
> Tout d'abord, merci beaucoup pour l'attention que vous porter à mon
> petit projet.
>
> J'ai grandement modifier le code source dans cette "v2", qui ne
> s'appelle déjà plus "parse_url" mais "url" (même si la fonction
> "parse_url" a toujours le même nom).
>
> J'ai créer:
> - Un type interne "urltype" à la place de l'ancien type "url"
> - Un type SQL "url" défini par les deux fonctions suivantes:
> - Une fonction "url_in" et son homologue "url_out" pour gérer le type de
> donnée "url".
> - Un type SQL "url_record", retourné par "parse_url(url)"
>
> http://www.d-sites.com/wp-content/uploads/2009/10/url.tar.gz
>
> Comme avant, il est compilable par un simple "make" et les requêtes SQL
> à exécuter sont présentes dans le fichier "url.sql".
>
> Voici quelques exemples:
> postgres=# SELECT parse_url('http://www.d-sites.com/index.php?q=query&r=postgresql#p2');
> parse_url
> --------------------------------------------------------------
> (http,,,www.d-sites.com,,/index.php,q=query&r=postgresql,p2)
> (1 row)
>
> postgres=# SELECT * FROM parse_url('http://www.d-sites.com/index.php?q=query&r=postgresql#p2');
> scheme | user | pass | host | port | path | query | fragment
> --------+------+------+-----------------+------+------------+----------------------+----------
> http | | | www.d-sites.com | | /index.php | q=query&r=postgresql | p2
> (1 row)
>
> postgres=# SELECT parse_url('http://www.d-sites.com/index.php?q=query&r=postgresql#p2', 'query');
> parse_url
> ----------------------
> q=query&r=postgresql
> (1 row)
>
> Toujours le même chose, qu'en pensez-vous ?
>
> Merci encore !
> Cordialement,
> Samuel.
>
> Le mercredi 21 octobre 2009 à 22:00 +0200, Samuel ROZE a écrit :
> > Bonjour à tous,
> >
> > Je viens ici demander quelques feedbacks à propos d'une fonctionnalité
> > que je suis en train de développer.
> >
> > Je suis en train de développer une série de fonctions permettant de
> > manipuler des adresses URL directement dans la base de données. Pour le
> > moment, j'ai fait le plus dur avec ces fonctions:
> > - url *parse_url_exec (char * url_str) - utilisée par les deux
> > fonctions suivantes
> > - Datum parse_url_key (PG_FUNCTION_ARGS) qui prend deux arguments:
> > - text: L'adresse URL
> > - text: Quoi récupérer dans cette liste: scheme (http, https, ftp,
> > etc...), user (le nom d'utilisateur quand il y a), pass (mot de passe
> > quand il y a), host (nom de domaine), path, query (requête - i.e. après
> > "?"), fragment (quel endroit de la page - i.e. après "#")
> > - Datum parse_url_record (PG_FUNCTION_ARGS) qui prend un seul argument
> > (text), l'adresse URL. Elle retourne un tuple de char*. i.e. un record.
> >
> > Pour simplifier la vie pour la récupération du record, j'ai fait un type
> > SQL "url" comme ceci:
> > ------------------------------------------------------------
> > CREATE TYPE url AS ("scheme" text, "user" text, "pass" text, "host"
> > text, "port" integer, "path" text, "query" text, "fragment" text);
> > ------------------------------------------------------------
> >
> > Les deux fonctions C sont définies comme ça:
> > ------------------------------------------------------------
> > CREATE FUNCTION parse_url(text, text) RETURNS text AS 'parse_url.so',
> > 'parse_url_key' LANGUAGE C STRICT;
> > ------------------------------------------------------------
> > CREATE FUNCTION parse_url (text) RETURNS url AS 'parse_url.so',
> > 'parse_url_record' LANGUAGE C STRICT;
> > ------------------------------------------------------------
> >
> > Vous pouvez télécharger le code dans une archive contenant le fichier .c
> > et .h, le Makefile ainsi que un fichier SQL qui contient ce que je vous
> > ai présenté ci-dessus.
> > http://www.d-sites.com/wp-content/uploads/2009/10/parse_url.tar.gz
> >
> > En toute logique, je vais continuer pour créer un "vrai" type de donnée
> > "url" utilisable en tant que champ SQL, qui permettra ensuite de bien
> > mieux gérer les adresses URL.
> >
> > Je souhaites avoir des retours de votre part avant d'en faire part à la
> > mailing "pgsql-hackers@" ainsi qu'avant publication sur mon blog.
> >
> > Note: cf en bas du mail pour les résultats de quelques requêtes sur ma
> > base de test en 8.4.1.
> >
> > Cordialement,
> > Samuel ROZE.
> > http://wwW.d-sites.com
> >
> > ------------------------------------------------------------
> > Sur une base de données PostgreSQL 8.4.1, avec le même code que dans
> > l'archive ci-dessus, compilé avec le même Makefile, après application
> > des 3 requêtes de création et type et de fonction, voilà le résultat
> > obtenu:
> >
> > postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'host');
> > parse_url
> > -----------------
> > www.d-sites.com
> > (1 row)
> >
> > postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'scheme');
> > parse_url
> > -----------
> > http
> > (1 row)
> >
> > postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'port');
> > parse_url
> > -----------
> >
> > (1 row)
> >
> > postgres=# SELECT parse_url('http://www.d-sites.com/test.php?query=info', 'port') IS NULL;
> > ?column?
> > ----------
> > t
> > (1 row)
> >
> > postgres=# SELECT * FROM parse_url('http://www.d-sites.com/test.php?query=info');
> > scheme | user | pass | host | port | path | query | fragment
> > --------+------+------+-----------------+------+-----------+------------+----------
> > http | | | www.d-sites.com | | /test.php | query=info |
> > (1 row)
> >
> > postgres=# SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968');
> > scheme | user | pass | host | port | path | query | fragment
> > --------+------+------+--------------------+------+-------------------------------+-------+----------
> > http | | | www.postgresql.org | | /docs/8.4/static/xfunc-c.html | | AEN44968
> > (1 row)
> >
> > postgres=# EXPLAIN ANALYSE SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968');
> > QUERY PLAN
> > -----------------------------------------------------------------------------------------------------------
> > Function Scan on parse_url (cost=0.00..0.01 rows=1 width=228) (actual time=0.036..0.039 rows=1 loops=1)
> > Total runtime: 0.087 ms
> > (2 rows)
> >
> > postgres=# EXPLAIN ANALYSE SELECT * FROM parse_url('http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44968', 'path');
> > QUERY PLAN
> > ---------------------------------------------------------------------------------------------------------
> > Function Scan on parse_url (cost=0.00..0.01 rows=1 width=32) (actual time=0.026..0.029 rows=1 loops=1)
> > Total runtime: 0.070 ms
> > (2 rows)
> >
>
>

Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> Un problème de mémoire... Ce que je ne comprend pas c'est pourquoi ça
> marche dans les autres cas et pas là.. Bizarre ! J'ai chercher
> différentes variables qui auraient pu être non-initialisées mais je ne
> voit pas...

Le type URL est un type de données à taille variable et doit donc suivre
les conventions des « varlena », en particulier pas de pointeur externe
dans la structure principale. Je t'encourage à regarder le module prefix
et le type de données prefix_range pour un exemple simple :)

De plus je me permets de rejoindre la positions d'autres intervenants,
utiliser une librairie de parsing d'URI existante me semble un meilleur
choix. Il reste à intégrer cela à PostgreSQL, attention aux soucis de
licence.

--
dim

Le 23 octobre 2009 10:33, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> a écrit :
> Le type URL est un type de données à taille variable et doit donc suivre
> les conventions des « varlena », en particulier pas de pointeur externe
> dans la structure principale. Je t'encourage à regarder le module prefix
> et le type de données prefix_range pour un exemple simple :)

Je n'arrive pas à bien comprendre comme ce type marche... Il y a-t-il
une partie de la documentation que j'aurais louper ?
De plus, je n'arrive pas non plus à trouver le code source du module
prefix et surtout, de son type "prefix_range"...

Je vais télécharger et regarder ce fichier dans la journée ou demain.
http://pgfoundry.org/frs/download.php/2424/prefix-1.0.0.tar.gz

Surtout, n'hésitez pas à m'expliquer un peu plus le système de gestion
des types à longueur variable ou à m'indiquer des urls l'expliquant
:-)

> De plus je me permets de rejoindre la positions d'autres intervenants,
> utiliser une librairie de parsing d'URI existante me semble un meilleur
> choix. Il reste à intégrer cela à PostgreSQL, attention aux soucis de
> licence.

Comme je l'ai dit dans un mail précédent, je n'aimes pas trop ne pas
maitriser le code... :/

Merci !
Samuel.

> --
> dim
>

On Fri, Oct 23, 2009 at 02:16:09PM +0200,
Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> wrote
a message of 38 lines which said:

> Surtout, n'hésitez pas à m'expliquer un peu plus le système de
> gestion des types à longueur variable ou à m'indiquer des urls
> l'expliquant

Je suis preneur, moi aussi, surtout que je suis en train d'en
développer un.

Le jeudi 22 octobre 2009 à 23:43:41, Dimitri Fontaine a écrit :
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> > #ifndef TextDatumGetCString
> > #define TextDatumGetCString(d) text_to_cstring((text *)
> > DatumGetPointer(d)) #endif
> >
> > Avec ça, je compile en 8.3 comme en 8.4 (je suis trop fatigué pour tester
> > sur les autres versions). Et j'utilise ça sans problème.
>
> Euh je croyais (de mémoire, pas vérifié) que text_to_cstring() c'était à
> partir de la 8.4 seulement ?
>

Oups, boulette de ma part. J'étais vraiment fatigué hier soir. Donc, non, ça
ne fonctionne pas sur 8.3 car, comme tu l'indiques, text_to_cstring n'existe
pas sur cette version.

> À mon tour de partager ma recette :
>
> text *txt = PG_GETARG_TEXT_P(0);
> char *str =
> DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(txt)));
>
> Ça marche depuis 8.1, j'ai pas testé avant.
>

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Bonjour,

Le vendredi 23 octobre 2009 à 10:33 +0200, Dimitri Fontaine a écrit :
> Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> > Un problème de mémoire... Ce que je ne comprend pas c'est pourquoi ça
> > marche dans les autres cas et pas là.. Bizarre ! J'ai chercher
> > différentes variables qui auraient pu être non-initialisées mais je ne
> > voit pas...
>
> Le type URL est un type de données à taille variable et doit donc suivre
> les conventions des « varlena », en particulier pas de pointeur externe
> dans la structure principale. Je t'encourage à regarder le module prefix
> et le type de données prefix_range pour un exemple simple :)

Je me suis renseigner (via Google ;-) ) sur le type "varlena".

Bonjour,

Le vendredi 23 octobre 2009 à 10:33 +0200, Dimitri Fontaine a écrit :
> Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> > Un problème de mémoire... Ce que je ne comprend pas c'est pourquoi ça
> > marche dans les autres cas et pas là.. Bizarre ! J'ai chercher
> > différentes variables qui auraient pu être non-initialisées mais je ne
> > voit pas...
>
> Le type URL est un type de données à taille variable et doit donc suivre
> les conventions des « varlena », en particulier pas de pointeur externe
> dans la structure principale. Je t'encourage à regarder le module prefix
> et le type de données prefix_range pour un exemple simple :)

Je me suis renseigner (via Google ;-) ) sur le type "varlena".

struct varlena
{
char vl_len_[4]; /* Do not touch this field directly! */
char vl_dat[1];
};

Il permet donc de stocker des données "char" dans "vl_dat", en utilisant
mempcy(VARDATA(..), source, ...) après avoir faire un SET_VARSIZE.

J'ai de même regarder le code source de "prefix" et j'ai vu que le
"prefix_range_in" retourne un varlena en réalité, grace à la fonction
"make_varlena"... De plus, le type prefix_range est défini comme ceci:

typedef struct {
char first;
char last;
char prefix[1]; /* this is a varlena structure, data follows */
} prefix_range;

Le "char prefix[1]" resemble à "char vl_data[1]", ça n'est peut-être pas
utile en fait ?

Sinon, il se trouve qu'en fait il y a ici uniquement une seule valeur
"char *" à remplir: "prefix". Seulement, moi j'en ai 7 ! :/
En effet, dans la fonction "build_pr", il y a:

int s = strlen(prefix) + 1;
prefix_range *pr = palloc(sizeof(prefix_range) + s);
memcpy(pr->prefix, prefix, s);
pr->first = first;
pr->last = last;

Comment je fait moi avec plein de champs ? Dans "s", je rajoute le
strlen de toutes les données ? Ouais mais là il faut toutes les passer
dans un argument ? Waou.. Plutôt faire deux types alors ? Un type
"urltype_internal" et "urltype_varlena" ?

Merci beaucoup.
Samuel.

Ça avance, ça avance ! :-)

postgres=# SELECT * FROM parse_url('http://www.postgresql.org');
NOTICE: url_in: str=http://www.postgresql.org
NOTICE: url_in: result=(C� host=www.postgresql.org path=(null)
NOTICE: url_size: url=(C� host=www.postgresql.org

scheme | user | pass | host | port | path | query |
fragment
--------+------+------+--------------------+------+------+-------+----------
http | | | www.postgresql.org | | | |
(1 row)

postgres=# DROP TABLE t1;
DROP TABLE
postgres=# CREATE TABLE t1 (my_url url);
CREATE TABLE
postgres=# INSERT INTO t1 VALUES ('http://www.postgresql.org'::url);
NOTICE: url_in: str=http://www.postgresql.org
NOTICE: url_in: result_� host=www.postgresql.org path=(null)
NOTICE: url_size: url_� host=www.postgresql.org
INSERT 0 1

Là, ça se gatte:

-----------------------------------------------------------------------------
postgres=# SELECT * FROM t1;
NOTICE: url_size: url_�
host=�
NOTICE: url_out: size=5078 url_�
host=� path=(null)
WARNING: detected write past chunk end in ExecutorState 0x2c05950







































-----------------------------------------------------------------------------
Avec les sauts à la ligne qui vont avec...

Comment peut-on expliquer ces résultats ?

Ci-joint mon fichier source.

Cordialement,
Samuel.

Le samedi 24 octobre 2009 à 12:19 +0200, Samuel ROZE a écrit :
> Bonjour,
>
> Le vendredi 23 octobre 2009 à 10:33 +0200, Dimitri Fontaine a écrit :
> > Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> > > Un problème de mémoire... Ce que je ne comprend pas c'est pourquoi ça
> > > marche dans les autres cas et pas là.. Bizarre ! J'ai chercher
> > > différentes variables qui auraient pu être non-initialisées mais je ne
> > > voit pas...
> >
> > Le type URL est un type de données à taille variable et doit donc suivre
> > les conventions des « varlena », en particulier pas de pointeur externe
> > dans la structure principale. Je t'encourage à regarder le module prefix
> > et le type de données prefix_range pour un exemple simple :)
>
> Je me suis renseigner (via Google ;-) ) sur le type "varlena".
>
> struct varlena
> {
> char vl_len_[4]; /* Do not touch this field directly! */
> char vl_dat[1];
> };
>
> Il permet donc de stocker des données "char" dans "vl_dat", en utilisant
> mempcy(VARDATA(..), source, ...) après avoir faire un SET_VARSIZE.
>
> J'ai de même regarder le code source de "prefix" et j'ai vu que le
> "prefix_range_in" retourne un varlena en réalité, grace à la fonction
> "make_varlena"... De plus, le type prefix_range est défini comme ceci:
>
> typedef struct {
> char first;
> char last;
> char prefix[1]; /* this is a varlena structure, data follows */
> } prefix_range;
>
> Le "char prefix[1]" resemble à "char vl_data[1]", ça n'est peut-être pas
> utile en fait ?
>
> Sinon, il se trouve qu'en fait il y a ici uniquement une seule valeur
> "char *" à remplir: "prefix". Seulement, moi j'en ai 7 ! :/
> En effet, dans la fonction "build_pr", il y a:
>
> int s = strlen(prefix) + 1;
> prefix_range *pr = palloc(sizeof(prefix_range) + s);
> memcpy(pr->prefix, prefix, s);
> pr->first = first;
> pr->last = last;
>
> Comment je fait moi avec plein de champs ? Dans "s", je rajoute le
> strlen de toutes les données ? Ouais mais là il faut toutes les passer
> dans un argument ? Waou.. Plutôt faire deux types alors ? Un type
> "urltype_internal" et "urltype_varlena" ?
>
> Merci beaucoup.
> Samuel.
>
>

Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> Surtout, n'hésitez pas à m'expliquer un peu plus le système de gestion
> des types à longueur variable ou à m'indiquer des urls l'expliquant

Il faut avoir une structure de données contigue en mémoire, pas de
pointeurs vers « ailleurs ». Typiquement au lieu de stocker deux char*
on va stocker un seul char[] et deux entiers, les longueurs des chaînes
à extraire dans la zone mémoire de taille variable.

Ensuite il faut faire un peu de présentation pour que PostgreSQL sache
travailler avec les données, c'est le make_varlena() de prefix.c. Quoi
faire exactement dépend de la version de PG:
#define PREFIX_SET_VARSIZE(p, s) (VARATT_SIZEP(p) = s)
#define PREFIX_SET_VARSIZE(p, s) (SET_VARSIZE(p, s))

>> De plus je me permets de rejoindre la positions d'autres intervenants,
>> utiliser une librairie de parsing d'URI existante me semble un meilleur
>> choix. Il reste à intégrer cela à PostgreSQL, attention aux soucis de
>> licence.
>
> Comme je l'ai dit dans un mail précédent, je n'aimes pas trop ne pas
> maitriser le code... :/

Pourquoi utiliser PostgreSQL plutôt que de réécrire ton propre SGBD, tu
maîtriserais certainement alors mieux le code du stockage de tes URLs,
et ne butterait pas sur la bonne représentation des varlena dans PG...

--
Dimitri Fontaine
PostgreSQL DBA, Architecte

Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> Comment je fait moi avec plein de champs ? Dans "s", je rajoute le
> strlen de toutes les données ? Ouais mais là il faut toutes les passer
> dans un argument ? Waou.. Plutôt faire deux types alors ? Un type
> "urltype_internal" et "urltype_varlena" ?

Dans ton type struct url je mettrais effectivement 7 entiers pour les
longueurs de chaque partie, et un seul char[] pour les données
variables. Il faut que ta structure de données soit contenue dans un
seul bloc de mémoire afin que PG puisse le déplacer, en mémoire et/ou
sur disque.

--
Dimitri Fontaine
PostgreSQL DBA, Architecte

Le lundi 26 octobre 2009 à 10:58 +0100, Dimitri Fontaine a écrit :
> Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> > Surtout, n'hésitez pas à m'expliquer un peu plus le système de gestion
> > des types à longueur variable ou à m'indiquer des urls l'expliquant
>
> Il faut avoir une structure de données contigue en mémoire, pas de
> pointeurs vers « ailleurs ». Typiquement au lieu de stocker deux char*
> on va stocker un seul char[] et deux entiers, les longueurs des chaînes
> à extraire dans la zone mémoire de taille variable.
>
> Ensuite il faut faire un peu de présentation pour que PostgreSQL sache
> travailler avec les données, c'est le make_varlena() de prefix.c. Quoi
> faire exactement dépend de la version de PG:
> #define PREFIX_SET_VARSIZE(p, s) (VARATT_SIZEP(p) = s)
> #define PREFIX_SET_VARSIZE(p, s) (SET_VARSIZE(p, s))
>

En gros, le char[] de ma structure "url" contient tout le contenu de mes
différents pointeurs actuels ? J'y ajoutes 7 entiers qui correspondront
à la taille de leur valeur ?

Ainsi, j'ai quelque chose comme ça:

struct {
char[1] data;
int scheme;
int user;
int pass;
...
} urltype;

Le char[1] contiendra toutes les données, "scheme" contiendra "4" si il
est égal à "http" par exemple, "user" 6 si user est "samuel" et "pass" 0
si pass est nul ?

Ainsi, data est : "httpsamuel"
Si j'ai bien compris... ? En gros, la valeur réelle du nom d'utilisateur
est contenu entre l'index "(int) scheme + 1" et "(int) scheme + (int)
user" ?

> >> De plus je me permets de rejoindre la positions d'autres intervenants,
> >> utiliser une librairie de parsing d'URI existante me semble un meilleur
> >> choix. Il reste à intégrer cela à PostgreSQL, attention aux soucis de
> >> licence.
> >
> > Comme je l'ai dit dans un mail précédent, je n'aimes pas trop ne pas
> > maitriser le code... :/
>
> Pourquoi utiliser PostgreSQL plutôt que de réécrire ton propre SGBD, tu
> maîtriserais certainement alors mieux le code du stockage de tes URLs,
> et ne butterait pas sur la bonne représentation des varlena dans PG...
>

Samuel ROZE <samuel(dot)roze(at)gmail(dot)com> writes:
> En gros, le char[] de ma structure "url" contient tout le contenu de mes
> différents pointeurs actuels ? J'y ajoutes 7 entiers qui correspondront
> à la taille de leur valeur ?

Voilà c'est l'idée. Une seule zone de mémoire à taille dynamique, mais
tu fais ce que tu veux dedans.

> Ainsi, j'ai quelque chose comme ça:
>
> struct {
> char[1] data;
> int scheme;
> int user;
> int pass;
> ...
> } urltype;

Sauf que le champs à taille variable *doit* être à la fin de la
structure. Sinon on est sur la même longueur d'ondes :)

--
Dimitri Fontaine
PostgreSQL DBA, Architecte