Forum Programmation.SQL Rendre une requête paramétrable persistante.

Posté par  .
Étiquettes : aucune
0
5
juin
2007
Hello !
Afin de me gagner du temps, j'aimerai intégrer à une base de données postgres un genre de requête préparée qui répondrait à cette requête :

select
prv_agt.num_agt,
dat_deb,
max(dat_ptj) as fin,
temps(sum(temps(temps))::int4) as fait,
temps((tps_est/(ndj_trv/2.)*(max(dat_ptj)-dat_deb+1))::int4) as prevu,
temps(sum(temps(temps))::int4 - (tps_est/(ndj_trv/2.)*(max(dat_ptj)-dat_deb+1))::int4) as diff
from
totaljournee,
prv_agt
where
totaljournee.num_agt = $1
and totaljournee.num_agt = prv_agt.num_agt
and (dat_ptj between dat_deb and dat_fin and getFinPeriode(dat_ptj) - 1 = dat_fin)
and dat_ptj <= $2
group by prv_agt.num_agt, dat_deb, tps_est, ndj_trv
order by 1;

Notez les $1 et $2 placés dans la clause where.
Évidement, je pourrais faire un prepare statement, mais le soucis de cette manipulation, c'est que son existence est limitée à la durée de vie de la connexion à la base. De plus, ce n'est pas partageable d'un utilisateur à un autre, etc.
J'ai bien essayé de faire une fonction, en précédant le code ci-dessus de
create type infos_prev as (num_agt int4, dat_deb date, dat_fin date, fait text, prevu text, diff text);
create or replace function rea_prev(integer, date) returns setof infos_prev as $$

et le faire suivre d'un $$ language SQL;
ça fonctionne, mais au lieu de me retourner des lignes du genre :

num_agt | dat_deb | fin | fait | prevu | diff
---------+------------+------------+-------+-------+--------
3 | 01-09-2006 | 01-09-2006 | 00:00 | 00:00 | 00:00
3 | 04-09-2006 | 08-09-2006 | 22:58 | 24:00 | -01:02


ça me retourne :

rea_prev
----------------------------------------------
(3,01-09-2006,01-09-2006,00:00,00:00,00:00)
(3,04-09-2006,08-09-2006,22:58,24:00,-01:02)


qui n'est pas exploitable en l'état....
Je m'en retourne vers vous donc, car là, je ne sais vraiment pas comment procéder pour arriver à mes fins.
Merci d'avance pour toute aide.

  • # Proc stock ?

    Posté par  . Évalué à 2.

    Et pourquoi pas une procédure stockée ?
    Il y a quelque chose qui t'en empêche ?

    • [^] # Re: Proc stock ?

      Posté par  . Évalué à 2.

      Je ne comprends pas ta remarque...
      Si je fais un create function plop ... ça me fait bien une procédure stockée, non ?
      C'est ce que j'ai indiqué dans mon message, le résultat obtenu n'est pas satisfaisant, car il ne correspond pas au résultat d'une requête avec des champs...

      • [^] # Re: Proc stock ?

        Posté par  (site web personnel) . Évalué à 1.

        Tu dois renvoyer un curseur (CURSOR)... en tout les cas en oracle on peut le faire et comme le pgsql est très proche du plsql d'oracle, on doit aussi pouvoir le faire avec postgres.

      • [^] # Re: Proc stock ?

        Posté par  . Évalué à 2.

        Hum je croyais que tu parlais de UDF en fait, d'où ma confusion.

      • [^] # Re: Proc stock ?

        Posté par  . Évalué à 1.

        Sans avoir testé, donc sans garantie aucune mais ca devrait marcher :

        CREATE OR REPLACE FUNCTION rea_prev(integer, date) RETURNS refcursor AS '
        DECLARE
        mycurs refcursor;
        BEGIN
        OPEN mycurs FOR
        select
        prv_agt.num_agt,
        dat_deb,
        max(dat_ptj) as fin,
        temps(sum(temps(temps))::int4) as fait,
        temps((tps_est/(ndj_trv/2.)*(max(dat_ptj)-dat_deb+1))::int4) as prevu,
        temps(sum(temps(temps))::int4 - (tps_est/(ndj_trv/2.)*(max(dat_ptj)-dat_deb+1))::int4) as diff
        from
        totaljournee,
        prv_agt
        where
        totaljournee.num_agt = $1
        and totaljournee.num_agt = prv_agt.num_agt
        and (dat_ptj between dat_deb and dat_fin and getFinPeriode(dat_ptj) - 1 = dat_fin)
        and dat_ptj <= $2
        group by prv_agt.num_agt, dat_deb, tps_est, ndj_trv
        order by 1;
        RETURN mycurs;
        END;' language plpgsql

        • [^] # Re: Proc stock ?

          Posté par  (site web personnel) . Évalué à 2.

          Juste pour mon info personnelle (je serais moins bête ce soir), pourquoi ne pas utiliser un SET OF RECORD et le RETURN NEXT qui va avec ?

          Est-ce juste pour la mémoire ? Y a-t-il une autre raison ?

          • [^] # Re: Proc stock ?

            Posté par  . Évalué à 1.

            pourquoi ne pas utiliser un SET OF RECORD et le RETURN NEXT qui va avec ?

            La raison principale est d'être cohérent avec les procédures stoquées du reste de l'univers. En plus sur les set of reccords, si on change les types des données d'une colonne, vu qu'il vaut mieux caster à la mimine derrière, on se retrouve assez rapidement à aller corriger tout un tas de lignes dans le code un peu partout.

            Donc personellement j'évite.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.