"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.
IMHO, a partially const-ified program is worse than no consts at all;
you find yourself introducing casts all over the place to deal with
transitions between code that knows things are const and code that
doesn't use const. So if we were going to do this I'd recommend doing
it whole-sale, and marking everything we could const in libpq-fe.h.
For example, most of the routines that accept or return char * really
ought to accept or return const char *; the pure inquiry functions ought
to take a const PGresult *, but not PQclear; etc. But that would make
it even more likely that app programmers would be forced to clean up
code that is working fine for them now. (We'd definitely have to clean
up the Postgres code that calls libpq.)
On the whole this seems like a can of worms better left unopened.
I certainly don't see it as something that one small patch will fix;
if we want to take const-safety seriously the effects will ripple
throughout the code...
regards, tom lane