<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.
I admit to a certain affinity to lisp-style programming and that does lead to
me tending to try to use initializers doing lots of work in expressions. But I
find I usually end up undoing them before I'm finished because I need to
include a statement or because too much work needs to be done with one
variable before some other variable can be initialized.
But including complex expensive function calls in initializers will probably
only confuse people trying to follow the logic of the code. Including
_bt_binsrch() as an initializer for example hides the bulk of the work this
function does.
People expect initializers to be simple expressions, macro calls, accessor
functions, and so on. Not to call out to complex functions that implement key
bits of the function behaviour.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
