Opción 1:CURRVAL () ;.
——————-
Por ejemplo:
INSERT INTO personas (apellido, nombre) VALUES (‘Perez’, ‘Juan’);
SELECT currval (‘personas_id_seq’);
El nombre de la secuencia debe ser conocido; en este ejemplo suponemos que las personas de la tabla tienen una columna de identificación creada con el pseudo-tipo SERIAL. Para evitar confiar en esto y sentirse más limpio, puede usar en su lugar pg_get_serial_sequence:
INSERT INTO personas (apellido, nombre) VALUES (‘Perez’, ‘Juan’);
SELECT currval (pg_get_serial_sequence (‘personas’, ‘id’));
Advertencia: currval () solo funciona después de un INSERT (que ha ejecutado nextval ()), en la misma sesión.
Opción 2: LASTVAL ();
————————–
Esto es similar al anterior, solo que no necesita especificar el nombre de la secuencia: busca la secuencia modificada más reciente (siempre dentro de su sesión, misma advertencia que la anterior).
Tanto CURRVAL como LASTVAL son seguros mientras no sean muy concurrentes. El comportamiento de la secuencia en PG está diseñado para que la sesión diferente no interfiera, por lo que no hay riesgo de condiciones de carrera (si otra sesión inserta otra fila entre mi INSERT y mi SELECT, todavía obtengo mi valor correcto).
Sin embargo, tienen un problema potencial sutil. Si la base de datos tiene algún TRIGGER (o RULE) que, al insertar en la tabla de personas, haga algunas inserciones adicionales en otras tablas … entonces LASTVAL probablemente nos dé un valor incorrecto. El problema puede ocurrir incluso con CURRVAL, si las inserciones adicionales se realizan en la misma tabla de personas (esto es mucho menos habitual, pero el riesgo aún existe).
Opción 3: INSERT con DEVOLUCIÓN
—————————————-
INSERT INTO personas (apellido, nombre) VALUES (‘Perez’, ‘Juan’) RETURNING id;
Esta es la forma más limpia, eficiente y segura de obtener la identificación. No tiene ninguno de los riesgos del anterior.
Inconvenientes? Casi ninguno: es posible que necesite modificar la forma en que llama a su instrucción INSERT (en el peor de los casos, tal vez su capa API o DB no espera que un INSERT regrese un valor); no es SQL estándar y está disponible desde Postgresql 8.2 (Dic 2006 …)
Conclusión: si puede, vaya a la opción 3. En otro lugar elija la 1.
Nota: todos estos métodos son inútiles si tiene la intención de obtener la última identificación insertada globalmente (no necesariamente en su sesión). Para esto, debe recurrir a seleccionar max (id) de la tabla (por supuesto, esto no leerá inserciones no confirmadas de otras transacciones).
Fuente
https://stackoverflow.com/questions/2944297/postgresql-function-for-last-inserted-id
Tutorials net 