Vous n'êtes pas identifié(e).
Non, c'est l'opérateur de concaténation.
Vous lui dites de prendre les chaînes à sa gauche et à sa droite pour créer une nouvelle chaîne contenant les deux.
Vous passez donc à execute la concaténation de l'ensemble des chaînes qui sont derrière lui. Les || entre chacune de ces chaînes sont donc impératifs, c'est ce qui lui permet de comprendre ce que vous voulez faire de ces chaînes.
Je pense que vous devriez rechercher ces quelques points dans la doc (comprendre complètement ce que vous êtes en train de faire), je crains que sinon vous fabriquiez du code que vous ne contrôlez pas, avec les conséquences catastrophiques que ça peut avoir.
Marc.
Hors ligne
|| est l'opérateur de concaténation de chaînes de caractères.
Guillaume.
Hors ligne
Tiens, y a de l'echo 
Plus sérieusement, j'ai l'impression que le bug de messages affichés en double et qui masquent les nouveaux messages est de retour, gleu…
Marc.
Hors ligne
ok, j'ai un autre soucis
quand je met un offset dans ma requète dynamique j'ai une erreur
execute 'select' || x|| 'from' 'tab' where 'y' '=' quote_literal(val) offset 1 LIMIT 1 into c;Hors ligne
j'ai une erreur du type l'argument de l'execute est null
merci pour vos réponses.
Hors ligne
Je présume que val vaut null ?
Si oui, quote_litteral vaudra null, ce qui fait que tout le reste vaudra null (la concaténation d'une chaîne avec une chaîne null retourne une chaîne null).
Remplacez quote_litteral par quote_nullable, qui est prévu pour gérer aussi les chaînes nulles dans les litteral.
Marc.
Hors ligne
non pas du tout
Hors ligne
Alors "x" ? C'est quoi ? Ça ne devrait pas être dans les quotes ? Il manque plein d'opérateurs de concaténation derrière de toutes façons, puisque vous utilisez des quotes pour indiquer la fin des chaînes…
Marc.
Hors ligne
c'est le offset qui pose problème car lorsque je l'utilise dans une requète non dynamique donc sans execute ça marche.
Hors ligne
non c'est des variables , c'est les paramètres de ma fonctions(x,y,val)
Hors ligne
Non, le problème, c'est que vous faîtes un EXECUTE, qui attend une chaîne de caractère.
Et que :
'select' || x|| 'from' 'tab' where 'y' '=' quote_literal(val) offset 1 LIMIT 1 into c;
est incompréhensible pour PostgreSQL: x est il une variable ? si oui jusque là c'est bon (mais dans ce cas, y n'es pas bon, puisque vous le mettez entre quotes)
ensuite, vous lui données une liste de chaînes de caractères : 'from' et 'tab', sans opérateur pour lui dire quoi en faire, puis un mot non protégé where, une nouvelle chaîne de caractère ('y'), encore une autre '=', à nouveau sans opérateur, un quote_literal qui est une fonction qui retourne une chaîne de caractère, toujours sans opérateur entre chaînes, et une série de mots-clés qui n'ont aucun sens pour execute, puisqu'il attend une chaine…
Comme dit plus haut, il faut vraiment que vous compreniez ce que vous êtes en train de faire avec ces chaînes de caractères, vous n'y arriverez pas sans.
Lisez déjà cette page sur la structure lexicale de SQL. Celle de PLPgSQL en est très proche.
Marc.
Hors ligne
pour ètre plus précis voila ma fonction
CREATE OR REPLACE FUNCTION test_multivaluate_dependancy(
left_attribut character varying,
right_attribut character varying,
val character varying,
val1 character varying,
tab character varying
)
returns integer as $$
DECLARE
i integer:=1 ;
i1 integer ;
bool boolean:=true ;
lio character varying;
BEGIN
--EXECUTE 'select ' || left_attribut || ' from '||tab||' where ' ||right_attribut|| '=' || quote_literal(val)
--into lio;
EXECUTE 'select '|| left_attribut || ' from ' ||tab||' where ' ||right_attribut|| '=' || quote_litera(val)
||' and ' ||left_attribut|| '=' || quote_literal(val1) offset 1 limit 1
into lio;
--select * from tab offset 1 limit 1;
return i;
END;
$$LANGUAGE 'plpgsql'
SECURITY DEFINER;Hors ligne
vous m'avez pas compris j'avais just posté la partie qui marchait pas mais pas tout le code pour aller plus vite mais bon, j'ai lu la doc sur votre lien assez rapidement faute de temps mais pour mon erreur je sais pas quoi faire
Hors ligne
Vu que la fonction est en security definer, c'est une raison supplémentaire de bien comprendre ce que vous faîtes: la fonction va s'exécuter avec les droits du propriétaire de celle-ci. C'est une énorme faille de sécurité que vous préparez dans votre application. Aucun des paramètres de la fonction ne doit être utilisé sans fonction quote, dour commencer (vos attributs par exemple).
Qu'est-ce qui vous garantit que left_attribut ne va pas valoir quelque chose comme 'toto; CREATE TABLE tmp AS SELECT * FROM ma_table_super_secrete; GRANT ALL TO PUBLIC ON tmp;' ou quelque chose de ce genre ?
Pour revenir à votre problème, vous avez bien un problème d'opérateur de concaténation manquant.
Mais ce que vous êtes en train de faire est très mauvais en termes de sécurité. Il faut que vous preniez du recul et que vous étudiez la question (recherchez des docs sur l'injection SQL par exemple), vous ne pouvez pas mettre en place une fonction comme celle là.
Marc.
Hors ligne
Mon application c'est pour un projet à la fac donc pour le moment ça c'est pas bien grave les failles de sécurité, mais merçi pour vos conseil car c'est vrai que je n'avais pas pensé aux injections sql.
Hors ligne