On 22.06.2011 01:51, Tom Lane wrote:
> I notice that the SSI code is rather heavily invested in function
> declarations like this:
>
> extern bool PageIsPredicateLocked(const Relation relation, const BlockNumber blkno);
>
> I find this to be poor style, and would like to see if there's any
> support for getting rid of the "const" keywords. My objections are
> twofold:
>
> 1. What such a "const" marking actually does is to forbid the function
> from changing the value of its local variable that received the passed
> parameter value. While you may or may not think that it's good style
> to avoid doing so, whether the function chooses to do that or not is
> surely no business of its callers'. Putting such a marking into the
> extern declaration doesn't create any useful API contract, it just means
> you'll have to change the declaration if you change the function's
> implementation.
Yeah, that makes no sense.
> 2. In cases such as "const Relation foo" where the parameter type is
> a typedeffed pointer, it is easy for readers to arrive at the false
> conclusion that this guarantees the function doesn't change the
> pointed-to structure. But it guarantees no such thing, because that
> construction is *not* equivalent to "const struct RelationData *foo";
> rather it means "struct RelationData * const foo", ie only the pointer
> is being const-ified, not that to which it points. The function can
> hack the struct contents, or pass the pointer to functions that do
> arbitrary things, and the compiler won't make a whimper. So I think
> that declarations like this are positively pernicious --- they'll
> mislead all but the most language-lawyerly readers.
Agreed. I did not realize the difference in the SSI patch. The intention
of the const declarations was clearly to document that the function
doesn't modify the data the pointer points to, but if the const
qualifier doesn't accomplish that, it's just wrong.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com