Re: Migration SQL Serveur 2008 vers PostgreSQL

Bonjour,

Le 05/01/2012 11:00, Dimitri Fontaine a écrit :
> "F. BROUARD / SQLpro"<sqlpro(at)club-internet(dot)fr> writes:
>> Voici un exemple de transactions infaisable sous PG :
> [...]
>> La procédure insère dans les tables T1 et T2 dans la cadre d'une
transaction
>> et, en cas de viol de la contrainte CHECK, annule la transaction et
insère
>> dans la table T3...
>
> C'est effectivement le cas qui nous pose problème, comme nous le
> disions hier. Merci pour cet exemple détaillé !
>
>> En sus PG ne permet pas de piloter le niveau d’isolation des
>> transactions de manière dynamique..
>
> Je suis assez étonné de cette affirmation :
>
> http://www.postgresql.org/docs/9.1/static/sql-set-transaction.html

lisez attentivement SVP :
"
The transaction isolation level cannot be changed after the first query
or data-modification statement (SELECT, INSERT, DELETE, UPDATE, FETCH,
or COPY) of a transaction has been executed. See Chapter 13 for more
information about transaction isolation and concurrency control.
"

ce qui signifie que dans une fonction PG cette commande est inopérante.

De plus PG n'implémente pas tous les niveaux d'isolation de la norme,
telle que SQL Server le fait :

"
The SQL standard defines one additional level, READ UNCOMMITTED. In
PostgreSQL READ UNCOMMITTED is treated as READ COMMITTED.
"

>
> On trouve cette commande aussi loin que j'ose remonter dans le temps…
>
>> Les transaction imbriquées, sont une autre difficultés (les sous
>> transactions cela n'existe pas, car par nature une transaction est
>> atomique
>
> Je suis étonné à nouveau :
>
> http://www.postgresql.org/docs/9.1/static/sql-savepoint.html
>
> SAVEPOINT establishes a new savepoint within the current
> transaction.
>
> A savepoint is a special mark inside a transaction that allows all
> commands that are executed after it was established to be rolled
> back, restoring the transaction state to what it was at the time >
of the savepoint.

SAVEPOINT est une chose et SQL Server le fait. Mais cela n'a rien, à
voir avec le principe des transactions imbriquées. Il s'agit de
transaction "partielles". Autrement dit, c'est la même transaction que
l'on saucissonne.

>
> Pour les différences de syntaxes, en parler au commité qui rédige le
> standard SQL : PostgreSQL s'applique à respecter le standard, ce qui
> est une position assez peu répandue finalement…

Là vous dites n'importe quoi...

Aucun SGBDR fût-il PG ne respecte la norme à la lettre...

Par exemple la recherche plain texte de PG est totalement hors norme
avec son ts_vector... Alors que la norme c'est le prédicat CONTAINS que
SQL server a effectivement mis en œuvre...

A +

--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************