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

> 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