On 11/2/06, Gregory Stark <[EMAIL PROTECTED]> wrote:
<[EMAIL PROTECTED]> writes:> 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! --Imad www.EnterpriseDB.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
