Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Général » cache lookup failed avec champ inet » 28/01/2013 10:09:06
=# SELECT * FROM pg_proc WHERE proname = 'network_eq' ;
proname | pronamespace | proowner | prolang | procost | prorows | provariadic | proisagg | proiswindow | prosecdef | proisstrict | proretset | provolatile | pronargs | pronargdefaults | prorettype | proargtypes | proallargtypes | proargmodes | proargnames | proargdefaults | prosrc | probin | proconfig | proacl
---------+--------------+----------+---------+---------+---------+-------------+----------+-------------+-----------+-------------+-----------+-------------+----------+-----------------+------------+-------------+----------------+-------------+-------------+----------------+--------+--------+-----------+--------
(0 rows)
#2 Re : Général » cache lookup failed avec champ inet » 28/01/2013 09:47:36
=# SELECT * FROM pg_proc WHERE oid = 920;
proname | pronamespace | proowner | prolang | procost | prorows | provariadic | proisagg | proiswindow | prosecdef | proisstrict | proretset | provolatile | pronargs | pronargdefaults | prorettype | proargtypes | proallargtypes | proargmodes | proargnames | proargdefaults | prosrc | probin | proconfig | proacl
---------+--------------+----------+---------+---------+---------+-------------+----------+-------------+-----------+-------------+-----------+-------------+----------+-----------------+------------+-------------+----------------+-------------+-------------+----------------+--------+--------+-----------+--------
(0 rows)
#3 Général » cache lookup failed avec champ inet » 25/01/2013 17:55:54
- laurentalpha
- Réponses : 4
Bonjour,
Je rencontre un souci avec l'utilisation du type de champ inet (pg 9.1) :
=# CREATE TABLE a (ip inet);
CREATE TABLE
=# INSERT INTO a VALUES ('10.1.1.1');
INSERT 0 1
=# INSERT INTO a VALUES ('10.1.1.2');
INSERT 0 1
=# INSERT INTO a VALUES ('10.2.1.2');
INSERT 0 1
=# INSERT INTO a VALUES ('10.2.1.1');
INSERT 0 1
=# SELECT * FROM a;
ip
----------
10.1.1.1
10.1.1.2
10.2.1.2
10.2.1.1
(4 rows)
=# SELECT * FROM a WHERE ip='10.1.1.1';
ERROR: cache lookup failed for function 920
=# SELECT * FROM a where ip = '10.1.1.1'::INET;
ERROR: cache lookup failed for function 920
Des idées ? Par avance merci.
#4 Général » Compteur cyclique optimisé » 20/11/2012 20:09:15
- laurentalpha
- Réponses : 3
Bonjour,
Je dois gérer un numéro unique par ligne, celui-ci ne devant pas dépasser 10 000 et rebouclant sur le premier numéro libre dans la suite (au fil du temps des lignes sont insérées et supprimées avec une marge suffisante, de sorte qu'il n'y ait jamais plus de 10 000 enregistrements). Un trigger sur delete permettrait de stocker les valeurs libérées pour pouvoir les utiliser, mais je me demandais s'il n'existait pas un mécanisme simple inhérent à Postgre. J'ai regardé du côté des séquences et de l'option CYCLE, mais la documentation indique que le rebouclage se fait sur min_value, et non sur la première valeur non utilisée.
Des idées ?
#5 Autres langages » plsh / netcat » 29/10/2012 17:51:34
- laurentalpha
- Réponses : 1
Bonjour,
Sur certains types d'évènements, je dois envoyer des données à un serveur TCP. J'utilise pour cela un netcat à l'intérieur d'une fonction plsh :
echo "p1;p2;p3" | netcat <ip>
L'envoi manuel (bash, user postgres) des données depuis la même machine fonctionne parfaitement :
# echo "p1;p2;p3" | netcat <ip>; echo $?
0
Dans le contexte de la fonction plsh, une erreur est renvoyée : $? = 1 (STDERR vide).
Le code suivant pose le même problème :
echo "p1;p2;p3" > /tmp/params
netcat <ip> < /tmp/params
Des suggestions ?
#6 Re : PL/pgSQL » [RESOLU] triggers chainés plsql / plsh » 10/09/2012 13:12:17
Julien,
Effectivement, j'avais oublié la solution la plus simple !
Merci !
#7 PL/pgSQL » [RESOLU] triggers chainés plsql / plsh » 10/09/2012 12:37:12
- laurentalpha
- Réponses : 2
Bonjour,
Sur INSERT et UPDATE, je dois lancer un certain nombre de commandes shell. Pas de souci pour l'utilisation de plsh. Cependant, pour ces traitements, je dois récupérer des informations qui se trouvent dans d'autres tables que celle ayant déclenchée le trigger. Vous l'aurez compris, je pourrais lancer une requête psql dans la fonction plsh pour récupérer les informations manquantes, mais je trouve cette solution peu élégante (descendre de postgre au niveau shell pour remonter chercher des informations...), et puis j'aime bien savoir ce qui est possible ou non, découvrant postgresql.
Mon idée est de créer un 1er trigger plsql sur les mêmes évènements de la table, qui sera appelé avant le trigger en plsh (ordre alphabétique). La documentation indique que dans ce cas les entrées/sorties entre triggers sont chainées. Le problème est qu'une fonction trigger doit retourner un type TRIGGER. Comment retourner des champs d'une autre table ou mieux, une liste de champs provenant de plusieurs tables ?
Voici, dans l'idée, ce que j'aimerais pouvoir faire :
CREATE OR REPLACE FUNCTION fct_get_additionals_infos() RETURNS RECORD AS $$
BEGIN
RETURN SELECT * FROM radreply WHERE radreply.username = NEW.username AND radreply.attribute = 'Framed-IP-Address';
END;
$$ LANGUAGE plpgsql;
Merci pour vos éclairages !
Pages : 1