-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On Fri, 25 Mar 2005, Tom Lane wrote:
>>> Does "\d pg_trigger" show that the tgargs column is of type bytea?
>
>> Umm no:
>
>> tgnargs | smallint | not null
>
> tgargs, not tgnargs.
Ooops, sorry. Ok, tgargs is of type bytea.
>>> Also, get the OID for this pg_trigger row and see if it shows up in
>>> objid or refobjid of any rows of pg_depend
>
>> Yes it is there
>
>> prod=# SELECT * from pg_depend WHERE objid =39053;
>> - -[ RECORD 1 ]------
>> classid | 16412
>> objid | 39053
>> objsubid | 0
>> refclassid | 1259
>> refobjid | 37564
>> refobjsubid | 0
>> deptype | a
>> - -[ RECORD 2 ]------
>> classid | 16412
>> objid | 39053
>> objsubid | 0
>> refclassid | 1259
>> refobjid | 37577
>> refobjsubid | 0
>> deptype | a
>
> Hmph. Those should be 'i' references to the foreign key constraint,
> not 'a' references to the relations. I suspect this database was
> carried forward from an ancient (pre-7.3) dump that defined the triggers
> by "CREATE CONSTRAINT TRIGGER" instead of "ALTER ADD FOREIGN KEY".
I haven't coded the application but AFAIKit was developed using 7.4 and
7.5(CVS); and we installed database on 8.0.1... This is a new app.
As a reminder, we ran pg_dump successfully before. After then we did
nothing on schemas, we didn't upgrade db server, etc.
> Have you ever run contrib/adddepend to update the definitions to be
> proper constraints?
Now I did, but the found constraints are not related to our problem... :(
I'll try to drop trigger on Monday night and see what will happen. We have
no up2date backup, except WAL logs... :(
Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdmsoft.com http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFCRTYGtl86P3SPfQ4RAjn7AKDrz+t6gsc53EAQ9UZAfAmgpZUwVACg532w
7c61IvIL5e2AjRg+5jV1BVw=
=Um2T
-----END PGP SIGNATURE-----