Recherche dans les tableaux

Bonjour,

lorsque j'ajoute une colonne dans une table avec pgAdminIII 1.8.4 ou
avec phpPgAdmin 4.2.1 (sous ma Mandriva 2009.0), je ne vois pas «
serial » ou « bigserial » dans la liste des types de données qui me
sont proposés.

Bon, OK, je n'ai qu'à utiliser la ligne de commandes mais
je voulais savoir si vous constatez la même chose, notamment avec
de précédentes versions de pgAdminIII et de phpPgAdmin...

Merci d'avance.
--
Denis

Denis Bitouzé a écrit :
> [...]
> lorsque j'ajoute une colonne dans une table avec pgAdminIII 1.8.4 ou
> avec phpPgAdmin 4.2.1 (sous ma Mandriva 2009.0), je ne vois pas «
> serial » ou « bigserial » dans la liste des types de données qui me
> sont proposés.
>
> Bon, OK, je n'ai qu'à utiliser la ligne de commandes mais
> je voulais savoir si vous constatez la même chose, notamment avec
> de précédentes versions de pgAdminIII et de phpPgAdmin...
>

Pour pgAdmin, serial et bigserial sont toujours là mais tout en bas de
la liste. Je suppose que cela doit aussi être le cas pour phpPgAdmin.

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

Le lundi 20/10/08 à 16h31,
Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :

> Pour pgAdmin, serial et bigserial sont toujours là mais tout en bas de
> la liste. Je suppose que cela doit aussi être le cas pour phpPgAdmin.

C'est cela même, merci !

En fait, j'avais créé la table dans pgAdmin où j'ai été induit en
erreur par l'ordre alphabétique trompeur : il y a une quantité
invraisemblable de types proposés, classés dans un ordre alphabétique
d'une rigueur à faire pâlir un tableur, suivis d'une liste des mêmes
types suffixés de [] (j'avoue que je ne sais pas à quoi cela correspond)
toujours impeccablement classés, et ce n'est qu'à la toute fin de ces
deux listes que l'on trouve, pas du tout où on les attendait, serial et
bigserial. Reconnaissons que, pour tromper l'ennemi, il n'y pas mieux :(

Ensuite, j'avais tenté de retravailler cette table dans phpPgAdmin et
que le type serial n'apparaissait pas car la colonne avait déjà été
créée. En fait, si on créé une colonne dans phpPgAdmin, le 1er type
proposé est SERIAL.

Désolé donc pour le bruit. Je vais essayer de trouver le temps de
suggérer un autre classement sur la liste pgadmin-support...

Merci encore !
--
Denis

Denis Bitouzé a écrit :
> Le lundi 20/10/08 à 16h31,
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>
>> Pour pgAdmin, serial et bigserial sont toujours là mais tout en bas de
>> la liste. Je suppose que cela doit aussi être le cas pour phpPgAdmin.
>
> C'est cela même, merci !
>
> En fait, j'avais créé la table dans pgAdmin où j'ai été induit en
> erreur par l'ordre alphabétique trompeur : il y a une quantité
> invraisemblable de types proposés, classés dans un ordre alphabétique
> d'une rigueur à faire pâlir un tableur,

Tous les types sont proposés, qu'ils soient internes à PostgreSQL ou
créés par des utilisateurs.

> suivis d'une liste des mêmes
> types suffixés de [] (j'avoue que je ne sais pas à quoi cela correspond)

Ce sont les mêmes types, mais en tant que tableau (tableau d'entiers,
tableau de chaînes, etc.).

> toujours impeccablement classés, et ce n'est qu'à la toute fin de ces
> deux listes que l'on trouve, pas du tout où on les attendait, serial et
> bigserial.

Si serial et bigserial sont à la fin, c'est que ce ne sont pas de vrais
types, mais des pseudo-types.

> Reconnaissons que, pour tromper l'ennemi, il n'y pas mieux :(
>

Oui. Malheureusement, je ne sais pas trop comment on peut faire mieux.
Mais je suis preneur de toute proposition.

Pour informations, Dave Page souhaite modifier la création de table pour
que l'ajout de colonnes soit plus simple.

> Ensuite, j'avais tenté de retravailler cette table dans phpPgAdmin et
> que le type serial n'apparaissait pas car la colonne avait déjà été
> créée. En fait, si on créé une colonne dans phpPgAdmin, le 1er type
> proposé est SERIAL.
>
> Désolé donc pour le bruit. Je vais essayer de trouver le temps de
> suggérer un autre classement sur la liste pgadmin-support...
>

Alors on s'y retrouvera :)

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

Le lundi 20/10/08 à 22h45,
Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :

> Tous les types sont proposés, qu'ils soient internes à PostgreSQL ou
> créés par des utilisateurs.

C'est fou ce que PostgreSQL est généreux en types de données ;)

> > suivis d'une liste des mêmes
> > types suffixés de [] (j'avoue que je ne sais pas à quoi cela
> > correspond)
>
> Ce sont les mêmes types, mais en tant que tableau (tableau d'entiers,
> tableau de chaînes, etc.).

OK.

> > toujours impeccablement classés, et ce n'est qu'à la toute fin de
> > ces deux listes que l'on trouve, pas du tout où on les attendait,
> > serial et bigserial.
>
> Si serial et bigserial sont à la fin, c'est que ce ne sont pas de
> vrais types, mais des pseudo-types.

Certes, mais ne sont-ils pas fréquemment utilisés ? Je suis tout sauf
expert en bases de données, donc peut-être devrais-je procéder
différemment, mais mes clés primaires sont toujours de type serial...

> > Reconnaissons que, pour tromper l'ennemi, il n'y pas mieux :(
> >
>
> Oui. Malheureusement, je ne sais pas trop comment on peut faire mieux.
> Mais je suis preneur de toute proposition.

Ben, euh, les mettre à leur place dans l'ordre alphabétique :)

> Pour informations, Dave Page souhaite modifier la création de table
> pour que l'ajout de colonnes soit plus simple.

Trèèèèès bonne idée ! ;)

> > Désolé donc pour le bruit. Je vais essayer de trouver le temps de
> > suggérer un autre classement sur la liste pgadmin-support...
> >
>
> Alors on s'y retrouvera :)

À bientôt :)
--
Denis

Le lundi 20 octobre 2008 à 22:45 +0200, Guillaume Lelarge a écrit :
[...]
>
> > suivis d'une liste des mêmes
> > types suffixés de [] (j'avoue que je ne sais pas à quoi cela correspond)
>
> Ce sont les mêmes types, mais en tant que tableau (tableau d'entiers,
> tableau de chaînes, etc.).

Bonjour,

On peut stocker des tableaux directement dans la base de données, sans
passer par un serialize et deserialize (php) par exemple ?
Pourriez-vous me donner plus d'informations à ce sujet ? Un lien?

Merci !

Samuel ROZE a écrit :
> Le lundi 20 octobre 2008 à 22:45 +0200, Guillaume Lelarge a écrit :
> [...]
>
>>> suivis d'une liste des mêmes
>>> types suffixés de [] (j'avoue que je ne sais pas à quoi cela correspond)
>>>
>> Ce sont les mêmes types, mais en tant que tableau (tableau d'entiers,
>> tableau de chaînes, etc.).
>>
>
> Bonjour,
>
> On peut stocker des tableaux directement dans la base de données, sans
> passer par un serialize et deserialize (php) par exemple ?
> Pourriez-vous me donner plus d'informations à ce sujet ? Un lien?
>
> Merci !
>
>
>
Bonsoir,

Cf. la doc. (en français, merci Guillaume, entre autres... !) :
http://docs.postgresqlfr.org/8.3/arrays.html

Tout y est fort bien expliqué.

François Figarola.

--
INTERNET CONSULT
Mas Guerido
6 rue Aristide Bergès
66330 CABESTANY

Tel 04.68.66.09.29
fax 04.68.66.99.50
* francois(dot)figarola(at)i-consult(dot)fr

2008/10/21 Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr>:
> Le lundi 20 octobre 2008 à 22:45 +0200, Guillaume Lelarge a écrit :
> [...]
>>
>> > suivis d'une liste des mêmes
>> > types suffixés de [] (j'avoue que je ne sais pas à quoi cela correspond)
>>
>> Ce sont les mêmes types, mais en tant que tableau (tableau d'entiers,
>> tableau de chaînes, etc.).
>
> Bonjour,
>
> On peut stocker des tableaux directement dans la base de données, sans
> passer par un serialize et deserialize (php) par exemple ?
> Pourriez-vous me donner plus d'informations à ce sujet ? Un lien?
>

Bonjour

http://docs.postgresqlfr.org/8.3/arrays.html

Ludovic

> Merci !
>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>

Bonjour à tous,

J'ai appris il y a quelques jours la possibilité de faire des tableaux
directement dans les tables. Je trouve ce principe très intéressant,
surtout dans le cas de mon utilisation.

Seulement, pour réellement justifier l'utilisation de cette "nouvelle"
technique de rangement dans la base de données, je voudrais savoir si je
peux faire une recherche dans une table en fonction d'une valeur d'un
tableau. Par exemple, j'ai admettons un champ "champs" (integer[]) dans
ma table "fermiers". Je veux savoir à qui est le champ n°12... Puis-je
faire une recherche du type:
SELECT nom FROM public.fermiers WHERE champs[*] = 12;
(cette requête ne marche pas :( )
Si ce n'est pas possible, je sais bien que je peux faire une table table
qui contiendras la "relation" entre la table "champs" et la table
"fermiers" par exemple.

Merci !
Cordialement, Samuel ROZE.

Bonjour,

2008/10/22 Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr>:
> Bonjour à tous,
>
> J'ai appris il y a quelques jours la possibilité de faire des tableaux
> directement dans les tables. Je trouve ce principe très intéressant,
> surtout dans le cas de mon utilisation.
>
> Seulement, pour réellement justifier l'utilisation de cette "nouvelle"
> technique de rangement dans la base de données, je voudrais savoir si je
> peux faire une recherche dans une table en fonction d'une valeur d'un
> tableau. Par exemple, j'ai admettons un champ "champs" (integer[]) dans
> ma table "fermiers". Je veux savoir à qui est le champ n°12... Puis-je
> faire une recherche du type:
> SELECT nom FROM public.fermiers WHERE champs[*] = 12;
> (cette requête ne marche pas :( )
> Si ce n'est pas possible, je sais bien que je peux faire une table table
> qui contiendras la "relation" entre la table "champs" et la table
> "fermiers" par exemple.
>

http://www.postgresql.org/docs/current/static/arrays.html
http://docs.postgresqlfr.org/8.3/arrays.html

La syntaxe ANY correspond surement à ce que tu veux faire.

# SELECT 1 = ANY ('{1,2,3}'::integer[]);
?column?
----------
t

Ludo

>
> Merci !
> Cordialement, Samuel ROZE.
>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>

Samuel ROZE a écrit :
> [...]
> J'ai appris il y a quelques jours la possibilité de faire des tableaux
> directement dans les tables. Je trouve ce principe très intéressant,
> surtout dans le cas de mon utilisation.
>
> Seulement, pour réellement justifier l'utilisation de cette "nouvelle"
> technique de rangement dans la base de données, je voudrais savoir si je
> peux faire une recherche dans une table en fonction d'une valeur d'un
> tableau. Par exemple, j'ai admettons un champ "champs" (integer[]) dans
> ma table "fermiers". Je veux savoir à qui est le champ n°12... Puis-je
> faire une recherche du type:
> SELECT nom FROM public.fermiers WHERE champs[*] = 12;
> (cette requête ne marche pas :( )

SELECT nom FROM public.fermiers WHERE 12 = ANY (champs);

Voir http://docs.postgresql.fr/8.3/arrays.html pour plus de détails.

> Si ce n'est pas possible, je sais bien que je peux faire une table table
> qui contiendras la "relation" entre la table "champs" et la table
> "fermiers" par exemple.
>

C'est souvent plus intéressant car indexable. Il y a bien le module
contrib intarray (http://docs.postgresql.fr/8.3/intarray.html) mais bon...

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

Le mercredi 22 octobre 2008 à 15:29 +0200, Samuel ROZE a écrit :
> Bonjour à tous,
>
> J'ai appris il y a quelques jours la possibilité de faire des tableaux
> directement dans les tables. Je trouve ce principe très intéressant,
> surtout dans le cas de mon utilisation.
>
> Seulement, pour réellement justifier l'utilisation de cette "nouvelle"
> technique de rangement dans la base de données, je voudrais savoir si je
> peux faire une recherche dans une table en fonction d'une valeur d'un
> tableau. Par exemple, j'ai admettons un champ "champs" (integer[]) dans
> ma table "fermiers". Je veux savoir à qui est le champ n°12... Puis-je
> faire une recherche du type:
> SELECT nom FROM public.fermiers WHERE champs[*] = 12;
> (cette requête ne marche pas :( )
> Si ce n'est pas possible, je sais bien que je peux faire une table table
> qui contiendras la "relation" entre la table "champs" et la table
> "fermiers" par exemple.

Autre petite question, peut-on faire la même chose, mais à l'inverse :

SELECT * FROM t1
LEFT JOIN t2 ON t1.monchamp = t2.montableau[*]
WHERE t2.id = 12;
[ou:]
SELECT * FROM t1, t2
WHERE t1.monchamp = t2.montableau[*]
AND t2.id = 12;

C'est-à-dire on sélectionne les enregistrements de t1 où le champ
"monchamp" est une valeur du tableau de "t2" pour l'ID (unique) 12.

>
>
> Merci !
> Cordialement, Samuel ROZE.
>
>