RE: Inconsistencia en foreign key

Podrias hacer :
select count(*) from pg_triggers where oid in ( select oid from pg_class
where relname=tutabla)

obviamente "tutabla" es el nombre de tu tabla ( userempre no? )
el valor que retorne este query tiene que ser 13 (al igual que
reltriggers).

Mas alla de que en el sistema, no hay posibilidad que un usuario
modifique datos de esta tabla, lo que quiero decir es que desde que en
Postgres existe esta posibildad , es posible ( valga la redundancia )
que ocurra, y de hecho es la unica forma que ocurra.

Espero te sirva...

Dorian Kuroki
DBAS.

Con fecha 17/4/2006, "dkuroki(at)dbas(dot)com(dot)ar" <dkuroki(at)dbas(dot)com(dot)ar>
escribió:

>pregunta . que version de postgres estas usando? es solo para ver la
>documentacion exacta.
>
>
>Con fecha 17/4/2006, "Jose Stragnari" <jose(at)mulleryasociados(dot)com(dot)ar>
>escribió:
>
>>Dorian,
>>
>> gracias por tu aclaración, pues desconocía como trabajaban las foreign key, pero luego de revisar el campo que comentas (reltriggers, el valor es 13) aún no encuentro el motivo, y si de algo estoy seguro es de que la pg_class nunca fue modificada por algún usuario.
>>
>>
>>
>>-----Mensaje original-----
>>De: dkuroki(at)dbas(dot)com(dot)ar [mailto:dkuroki(at)dbas(dot)com(dot)ar]
>>Enviado el: Lunes, 17 de Abril de 2006 05:23 p.m.
>>Para: Jose Stragnari; pgsql-es-ayuda(at)postgresql(dot)org
>>Asunto: Re: [pgsql-es-ayuda] Inconsistencia en foreign key
>>
>>Jose,
>>Postgresql implementa las foreign keys mediante un trigger. Esto es, cada
>>vez que se hace un insert, update o delete de una tabla con FK, este
>>trigger ejecuta una funcion interna que "se fija" en la otra tabla si
>>los datos estan ok.
>>Por esta razon es que si estas haciendo un trace de los statements (
>>log_statement=all ) podes ver algunos queries del tipo "SELECT 1 FROM
>>ONLY tabla". estos queries los ejecuta esta funcion.
>>Ahora, el tema pasa porque en postgres podes forzar a una tabla a que no
>>ejecute triggers modificando un dato en la tabla de catalogo pg_class .
>>el campo en custion es reltriggers.
>>reltriggers es un valor smallint que responde a la cantidad de triggers
>>de la tabla. si este valor es 0 para una tabla dada, ningun trigger va a
>>ser ejecutado, aun los de la foreign key. ( considera que la tabla
>>pg_class puede ser updateada como cualquier tabla )
>>verifica ese valor si es correcto, porque de esa forma puede haber
>>"entrado" un valor inconsistente.
>>
>>esto puede servir de "artilugio" para tareas tediosas en migraciones
>>por ejemplo.
>>espero que sea claro.
>>
>>Dorian Kuroki
>>DBAS.
>>
>>
>>
>>
>>Con fecha 17/4/2006, "Jose Stragnari" <jose(at)mulleryasociados(dot)com(dot)ar>
>>escribió:
>>
>>>Hola,
>>>
>>>
>>>
>>> Quisiera saber si alguna vez a alguno le sucedió que aparezca una inconsistencia con una foreign key como me sucede en este momento. Se trata de dos tablas, userempre que referencia con uno de sus campos a la tabla xrpuser. La referencia es la siguiente:
>>>
>>>
>>>
>>>ALTER TABLE userempre
>>>
>>> ADD CONSTRAINT "FK_userempre_xrpusers" FOREIGN KEY (idxrpuser)
>>>
>>> REFERENCES xrpusers (idxrpuser) MATCH SIMPLE
>>>
>>> ON UPDATE CASCADE ON DELETE CASCADE;
>>>
>>>
>>>
>>>El problema lo encuentro en la tabla userempre con un dato (2177) que no tiene su correspondiente registro en la tabla xrpuser. De acuerdo a la documentación de Postgresql no existe la posibilidad como en Oracle de que las constraints tengan diferentes estados (Enable Validate, Enable Novalidate, Disable Validate, Disable Novalidate). En todos los casos posibles para definir la opción ON DELETE de la constraint (NO ACTION, RESTRICT, CASCADE o SET NULL), no encuentro la manera de reproducir este, que a primera vista parece un error. Inclusive al borrar e intentar crear la constraint nuevamente no lo permite, pues este dato viola la restricción.
>>>
>>>
>>>
>>>No se si estoy pasando por alto algo en relación a las foreign key de postgres, así que si alguien sabe de que se trata le agradecería cualquier aclaración.
>>>
>>>
>>>
>>>Gracias
>>>
>>>
>>>
>>>
>>>
>>>José Luis Stragnari
>>>
>>>jose(at)mulleryasociados(dot)com(dot)ar
>>>
>>>Córdoba - Argentina
>>>
>>
>>
>>
>>---------------------------(fin del mensaje)---------------------------
>>TIP 3: si publicas/lees desde Usenet, por favor envía "subscribe-nomail"
>> a majordomo(at)postgresql(dot)org para que tus mensajes puedan llegar
>> a los suscriptores de la lista
>
>---------------------------(fin del mensaje)---------------------------
>TIP 4: No hagas 'kill -9' a postmaster