On 11/2/06, Gregory Stark <[EMAIL PROTECTED]> wrote:

> I would probably write that as:
> ________________________________________________________________________
> static TransactionId
> _bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
>                  Buffer buf, ScanKey itup_scankey)
> {
>     TupleDesc    itupdesc = RelationGetDescr(rel);
>     int          natts    = rel->rd_rel->relnatts;
>     Page         page     = BufferGetPage(buf);
>     OffsetNumber maxoff   = PageGetMaxOffsetNumber(page);
>     BTPageOpaque opaque   = (BTPageOpaque) PageGetSpecialPointer(page);
>     OffsetNumber offset   = _bt_binsrch(rel, buf, natts, itup_scankey, false);
>     Buffer       nbuf     = InvalidBuffer;

The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.

For example, if later you find out you have to, say, lock a table before the
itupdesc initializer then all of the sudden you have to rip out all the
initializers and rewrite them as assignments after the statement acquiring the
table lock.

Well, its about the coding style. And I doubt there exists a data type
which may not have
an initializer. A NULL / Zero is an option in all cases and you can do
whatever you want to assign it a value immediately after the
initialization section. My two cents!


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to