Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Perhaps this coding convention is too error-prone and ought to be
>> changed to have two different routine names, say "heap_open[r]"
>> and "heap_open[r]_noerr". Opinions anyone?
> We already have heap_open and heap_openr. Seems another is too hard.
> Better to give them a parameter to control it. The API is confusing
> enough.
It is confusing, but we have here graphic evidence that the way it's
currently done is confusing. In a quick check, I found several other
cases of the same error that must have crept in over the past year or
so. So I'm now convinced that we'd better change the API of these
routines to make it crystal-clear whether you are getting a check for
open failure or not.
I like a different routine name better than a check-or-no-check
parameter. If you invoke the no-check case then you *MUST* have a check
for failure return --- forgetting to do this is exactly the problem.
So I think it should be harder to get at the no-check case, and you
should have to write something that reminds you that the routine is not
checking for you. Thus "heap_open_noerr" (I'm not particularly wedded
to that suffix, though, if anyone has a better idea for what to call
it). A parameter would only be useful if the same calling code might
reasonably do different things at different times --- but either there's
a check following the call, or there's not.
regards, tom lane