| From: | Marc Cousin <mcousin(at)sigma(dot)fr> |
|---|---|
| To: | pgsql-fr-generale(at)postgresql(dot)org |
| Cc: | philippe(dot)beaudoin(at)bull(dot)net |
| Subject: | Re: Réf. : Re: [pgsql-fr-generale] Transaction en erreur sur CLOSE ou INSERT |
| Date: | 2009-01-12 09:07:21 |
| Message-ID: | 200901121007.21319.mcousin@sigma.fr |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-fr-generale |
Le Sunday 11 January 2009 17:09:37 philippe(dot)beaudoin(at)bull(dot)net, vous avez
écrit :
> Merci Guillaume et William pour vos apports, en plein week-end...
> Je vais donc proposer les pistes suivantes :
> Pour les CLOSE curseur :
> - partir du principe qu'il faut éviter les CLOSE préventifs,
> - pour les cas où vraiment, ces CLOSE préventifs ont une justification,
> utiliser un savepoint, au prix de 2 échanges supplémentaires avec le
> serveur (la consultation de pg_cursor ne me semblant pas assez portable).
> Pour la détection des doublons sur INSERT, de :
> - envisager l'utilisation de fonctions gérant globalement des INSERT/UPDATE
> en un seul échange client/serveur (la solution de l'update avant insert
> aboutissant le plus souvent à 2 échanges).
>
> Cordialement. Philippe.
>
Si pour les fermetures de curseurs, le but du code c'est de fermer tout ce qui
pourrait traîner des prédécesseurs ayant utilisé la session, il y a CLOSE
ALL. Ca permettra de garder le code presque en l'état, et de ne pas avoir
d'erreur ... http://www.postgresql.org/docs/8.3/interactive/sql-close.html
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephane Bortzmeyer | 2009-01-12 10:26:22 | Re: Transaction en erreur sur CLOSE ou INSERT |
| Previous Message | philippe.beaudoin | 2009-01-11 16:09:37 | Réf. : Re: Transaction en erreur sur CLOSE ou INSERT |