"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
