-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rafa Couto wrote:
> I understand "FOR UPDATE" clause is locking while is selecting rows
> only. It does not secure atomic execution from 'SELECT' to 'UPDATE' in
> next statement. Is not it?
Locks adhere until the transaction ends. I included links to
Rafa Couto wrote:
I have got a plpgsql function:
-- BEGIN;
SELECT min(id) INTO _contacto_id FROM contactos
WHERE contactos.operadora_id IS NULL AND contactos.actividad_id
= _actividad_id;
UPDATE contactos SET operadora_id = _operadora_id WHERE id = _contacto_id;
-- COMMI
Rafa Couto wrote:
2005/5/20, Andrew Hammond <[EMAIL PROTECTED]>:
The solution to your problem is locking (or concurrency control if you
prefer). While we're at it, we might as well optimize your statement a
little too using ORDER BY with LIMIT instead of min().
SELECT id INTO _contacto_id
FRO
2005/5/20, Andrew Hammond <[EMAIL PROTECTED]>:
> The solution to your problem is locking (or concurrency control if you
> prefer). While we're at it, we might as well optimize your statement a
> little too using ORDER BY with LIMIT instead of min().
>
> SELECT id INTO _contacto_id
> FROM contacto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The manual is correct, you can not do transactions within a procedure
since the procedure must be called within a transaction. If you're
working with postgres 8, you can achieve similar functionality using
checkpoints. But that won't solve the problem
I have got a plpgsql function:
CREATE FUNCTION nueva_llamada(integer, integer) RETURNS integer
as
DECLARE
_operadora_id ALIAS FOR $1;
_actividad_id ALIAS FOR $2;
_contacto_id integer;
BEGIN
-- BEGIN;
SELECT min(id) INTO _contacto_id FROM contactos
WHERE contactos.operadora_
