mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Indent new rename.c for Tom Lane.

Browse Source
This commit is contained in:
Bruce Momjian 2001-11-12 01:34:50 +00:00
parent b52950cc3d
commit a83bd89d00
1 changed files with 56 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
src/backend/commands/rename.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/commands/Attic/rename.c,v 1.62 2001/11/12 00:46:36 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/commands/Attic/rename.c,v 1.63 2001/11/12 01:34:50 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -487,8 +487,8 @@ update_ri_trigger_args(Oid relid,
/*
* It is an RI trigger, so parse the tgargs bytea.
*
* NB: we assume the field will never be compressed or moved
* out of line; so does trigger.c ...
* NB: we assume the field will never be compressed or moved out of
* line; so does trigger.c ...
*/
tgnargs = pg_trigger->tgnargs;
val = (bytea *) fastgetattr(tuple,
@ -510,10 +510,10 @@ update_ri_trigger_args(Oid relid,
/*
* Figure out which item(s) to look at. If the trigger is
* primary-key type and attached to my rel, I should look at
* the PK fields; if it is foreign-key type and attached to my
* rel, I should look at the FK fields. But the opposite rule
* holds when examining triggers found by tgconstrrel search.
* primary-key type and attached to my rel, I should look at the
* PK fields; if it is foreign-key type and attached to my rel, I
* should look at the FK fields. But the opposite rule holds when
* examining triggers found by tgconstrrel search.
*/
examine_pk = (tg_type == RI_TRIGGER_PK) == (!fk_scan);
@ -608,9 +608,9 @@ update_ri_trigger_args(Oid relid,
heap_close(tgrel, RowExclusiveLock);
/*
* Increment cmd counter to make updates visible; this is needed
* in case the same tuple has to be updated again by next pass
* (can happen in case of a self-referential FK relationship).
* Increment cmd counter to make updates visible; this is needed in
* case the same tuple has to be updated again by next pass (can
* happen in case of a self-referential FK relationship).
*/
CommandCounterIncrement();
}