Linos escribió: > 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?
El problema es que para hacer un select para verificar si necesitas update o insert, necesitarias bloquear la tabla de antemano; de lo contrario puede pasar que hagas el select, diga que no esta el registro, y justo algun otro proceso lo inserte antes que tu alcances a insertarlo. Si no te complica bloquear la tabla, entonces creo que este procedimiento seria lo mas rapido. (Digo "creo" porque es posible que la otra alternativa es hacerlo con un "upsert" usando un savepoint. Hay un procedimiento de ejemplo de esto en la documentacion de Postgres. La gracia del upsert es que solo tienes que hacer un recorrido de la tabla en el caso que funcione a la primera; en cambio si bloqueas la tabla tienes que hacer primero el select y despues el insert o update, o sea son dos recorridos en todos los casos. Sin embargo tiene la desventaja de tener que crear y destruir el savepoint por cada registro). -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ "After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was amazing when I first started using it at 7.2, and I'm continually astounded by learning new features and techniques made available by the continuing work of the development team." Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php -- TIP 4: No hagas 'kill -9' a postmaster
