On 11/2/06, Gregory Stark <stark@enterprisedb.com> wrote:
> <korryd@enterprisedb.com> 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