commented out code - Mailing list pgsql-hackers

From Peter Eisentraut
Subject commented out code
Date
Msg-id 328e4371-9a4c-4196-9df9-1f23afc900df@eisentraut.org
Whole thread Raw
Responses Re: commented out code
List pgsql-hackers
There are many PG_GETARG_* calls, mostly around gin, gist, spgist code, 
that are commented out, presumably to indicate that the argument is 
unused and to indicate that it wasn't forgotten or miscounted.  Example:

...
     StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);

     /* Oid      subtype = PG_GETARG_OID(3); */
     bool       *recheck = (bool *) PG_GETARG_POINTER(4);
...

But keeping commented-out code updated with refactorings and style 
changes is annoying.  (Also note that pgindent forces the blank line.)

One way to address this is to de-comment that code but instead mark the 
variables unused.  That way the compiler can check the code, and the 
purpose is clear to a reader.  Example:

     pg_attribute_unused() Oid subtype = PG_GETARG_OID(3);

(This is the correct placement of the attribute under forward-looking 
C23 alignment.)

I have attached a patch for that.

An alternative is to just delete that code.  (No patch attached, but you 
can imagine it.)

Some particular curious things to check in the patch:

- In contrib/hstore/hstore_gin.c, if I activate the commented out code, 
it causes test failures in the hstore test.  So the commented out code 
is somehow wrong, which seems bad.  Also, maybe there is more wrong code 
like that, but which doesn't trigger test failures right now?

- In src/backend/utils/adt/jsonfuncs.c, those calls, if activated, are 
happening before null checks, so they are not correct.  Also, the "in" 
variable is shadowed later.  So here, deleting the incorrect code is 
probably the best solution in any case.

- In doc/src/sgml/gist.sgml, this is the source of the pattern, it 
actually documents that you should write your functions with the 
commented out code.  We should think about an alternative way to 
document this.  I don't see the "subtype" argument documented anywhere 
in the vicinity of this, so I don't know what the best advice would be. 
Just silently skipping an argument number might be confusing here.

Thoughts?

Attachment

pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Next
From: Nathan Bossart
Date:
Subject: Re: Popcount optimization for the slow-path lookups