Thus spake Tom Lane
> "D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> > In interfaces/libpq/libpq-fe.h there are some structures that include
> > char pointers. Often one would expect the user to send const strings
> > to the functions using these pointers. The following keeps external
> > programs from failing when full error checking is enabled.
>
> Yeah, I thought about const-ifying libpq's interfaces when I was working
> on it last summer, but desisted for fear of breaking existing
> application code. The trouble with adding a few const keywords is that
> they propagate. Just as you had to change some of libpq's internal
> variables from "char *" to "const char *" after modifying these structs,
> so an application program would likely find that it needed to const-ify
> some of its declarations to avoid errors/warnings created by this
> change. So, I didn't do it for fear of complaints.
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.
Not that I don't think that return values should be changed where it
is appropriate as well but this change doesn't do that.
> code that is working fine for them now. (We'd definitely have to clean
> up the Postgres code that calls libpq.)
Like what? I compiled the whole tree including my PyGreSQL module
and all the changes were inside libpq as I expected.
> 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.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
