Обсуждение: Referential constraints in version 8

We have just finished upgrading Postgres from 7.2 to 8, and I must live
right or something because there was only one glitch.  When the dump
from 7.2 was restored into 8, some foreign key references which should
have been initially deferred had become non-deferrable.  I had to
re-define those references by dropping the corresponding triggers and
using ALTER TABLE to put them back as foreign key constraints, which
seems to have fixed the problem.  However, those references which I
re-defined now show up explicitly in the table descriptions as foreign
key constraints, and the corresponding triggers are not listed.  This
is great since it makes the table descriptions much more intelligible,
but my concern is that all the other references which I didn't
re-define still show as triggers and not as foreign key constraints.
Is this just a cosmetic issue with psql's table description, or is
there actually a functional difference?  Should I re-define all the
other foreign key constraints to be safe?

Thanks!

Bob Smith
Hammett & Edison, Inc.
bsmith@h-e.com

On Fri, Apr 15, 2005 at 12:31:28AM -0700, Bob Smith wrote:
> We have just finished upgrading Postgres from 7.2 to 8, and I must live
> right or something because there was only one glitch.  When the dump
> from 7.2 was restored into 8, some foreign key references which should
> have been initially deferred had become non-deferrable.  I had to
> re-define those references by dropping the corresponding triggers and
> using ALTER TABLE to put them back as foreign key constraints, which
> seems to have fixed the problem.  However, those references which I
> re-defined now show up explicitly in the table descriptions as foreign
> key constraints, and the corresponding triggers are not listed.  This
> is great since it makes the table descriptions much more intelligible,
> but my concern is that all the other references which I didn't
> re-define still show as triggers and not as foreign key constraints.
> Is this just a cosmetic issue with psql's table description, or is
> there actually a functional difference?  Should I re-define all the
> other foreign key constraints to be safe?

I suggest you run contrib/adddepend against that database.  It will try to
add the missing information to the system catalogs so that the FKs
appear as such and not triggers.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"

Bob Smith <bsmith@h-e.com> writes:
> We have just finished upgrading Postgres from 7.2 to 8, and I must live
> right or something because there was only one glitch.  When the dump
> from 7.2 was restored into 8, some foreign key references which should
> have been initially deferred had become non-deferrable.  I had to
> re-define those references by dropping the corresponding triggers and
> using ALTER TABLE to put them back as foreign key constraints, which
> seems to have fixed the problem.  However, those references which I
> re-defined now show up explicitly in the table descriptions as foreign
> key constraints, and the corresponding triggers are not listed.  This
> is great since it makes the table descriptions much more intelligible,
> but my concern is that all the other references which I didn't
> re-define still show as triggers and not as foreign key constraints.
> Is this just a cosmetic issue with psql's table description, or is
> there actually a functional difference?  Should I re-define all the
> other foreign key constraints to be safe?

Yeah, you should --- if it shows as a trigger then the system hasn't
fully grokked it.  The contrib/adddepend script may help you.

            regards, tom lane