Re: [HACKERS] Adding some const keywords to external interfaces

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> Actually, all the changes should be internal to our own code.  Functions
> that take const char pointers can still send non-const pointers.  The
> errors would be generated  if we changed the return value of the library
> functions, not the arguments.

True, adding const decorations to function arguments is fairly harmless
from the caller's point of view, but it also provides only a small
fraction of the error checking available with a fully const-ified
interface.

More to the point, the patch you submitted was *not* adding consts to
function arguments, it was adding consts to struct fields.  That *can*
cause errors in calling code, if the caller happens to copy the value
of such a field into a local variable that's not declared const, pass
it as an argument to a function not marked const, etc.

I guess my question is "why start here?".

>> if we want to take const-safety seriously the effects will ripple
>> throughout the code...

> I would love to see const-safety given more attention but certainly
> we should make sure our external interfaces are correct so that people
> writing to them have the opportunity to do full error checking.

Well, that's exactly my point.  I don't see much value in doing a
half-baked job of decorating the interface with const declarations;
you don't get much real error checking that way.  If we are going to
take const-safety seriously then we need to do the whole job.

That's a fair amount of work that will impact outside applications as
well as a lot of our own code (certainly most of interfaces/ and bin/,
more if we start const-ifying the backend's internal interfaces).
I think we need a pgsql-hackers consensus and commitment to the idea
before we start doing it.
        regards, tom lane