Re: sobre savepoints

tambien podria dentro de la funcion quizas lanzar primero el select y segun lanzar un
insert o un update, no? deberia ser mas rapido que el savepoint? lo que no se como
resolver en plpsql es el tema del numero de columnas variable pero supongo q habra alguna
forma, no?

Alvaro Herrera escribió:
> Linos escribió:
>
>> begin ----- savepoint ---- insert ---- releasesavepoint ---- savepoint
>> ---- insert ----- releasesavepoint ---- savepoint --- insert(error) ---
>> rollback to savepoint --- update --- releasesavepoint --- 20000 registros
>> mas ---- commit
>>
>> Lo cual a traves de una linea lenta ralentiza considerablemente. Supongo
>> que debe haber alguna manera mejor de hacer esto que evidentemente yo no
>> conozco, se puede desactivar este modo para que la transaccion siga con
>> un error hasta que yo haga un rollback especifico?
>
> No. Todos los errores dejan la transaccion en estado "abortado", del
> cual solo puedes salir abortandola completamente o bien con ROLLBACK TO
> savepoint.
>
> (Efectivamente lo que el codigo hace es un "rollback automatico"
> internamente)
>
>> otra manera que habia pensado es hacer una funcion para los inserts (q
>> cambiara a update si existe el registro) pero las columnas cambian no
>> solamente para cada tabla si no a veces en cada insert, se generan
>> con unos triggers automaticamente y no se si se podria hacer o incluso
>> si interesaria hacerlo. Me podrian echar un cable con esto? gracias.
>
> Si el problema es la cantidad extra de ordenes que tienes que enviar
> desde el cliente, creo que seria una ganancia enorme hacerlo en una
> funcion del lado del servidor, usando bloques EXCEPTION. Ahora, tienes
> que tener en cuenta que EXCEPTION crea un nuevo savepoint cada vez, asi
> que si la ralentizacion viene por el lado de crear los savepoints (lo
> cual no seria raro, porque los savepoints son relativamente lentos)
> entonces va a seguir siendo un cuello de botella.
>
> Lo otro que podrias hacer, quizas, es intentar con PGLoader.
>