Re: cleanup execTuples.c - Mailing list pgsql-patches

From Tom Lane
Subject Re: cleanup execTuples.c
Date
Msg-id 4783.1069346051@sss.pgh.pa.us
Whole thread Raw
In response to cleanup execTuples.c  (Neil Conway <neilc@samurai.com>)
Responses Re: cleanup execTuples.c  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> As a result, ExecInitScanTupleSlot(), ExecInitResultTupleSlot(),
> ExecTypeFromTL(), and ExecCleanTypeFromTL() are now all trivial
> (1 line) functions. I could have replaced these with macros, but I
> didn't: does anyone thinks that would be worth doing?

Please use names for the replacement routines that are more clear than
"fooInternal".  You can get away with that kind of name for a static
function, but I think globally visible ones should have more meaningful
names.

For ExecTypeFromTLInternal, maybe use ExecTupDescFromTL, which is a more
accurate name in the first place ...

As for the Slot functions, I agree with getting rid of the macros, which
seem to add little except obfuscation.  But I see no need to introduce
an extra layer of calls.  Why not make them all go directly to
ExecAllocTableSlot(estate->es_tupleTable)?  I don't see that
  planstate->ps_ResultTupleSlot = ExecInitExtraTupleSlot(estate);
is better than
  planstate->ps_ResultTupleSlot = ExecAllocTableSlot(estate->es_tupleTable);

            regards, tom lane

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: Add GUC setting to make created tables default to
Next
From: Neil Conway
Date:
Subject: fix compile warning