> 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...
Well said. I have always suspected const would ripple through the code,
but had never heard it described so well.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
