,--- I/Alex (Tue, 13 Dec 2011 07:55:45 -0500) ----*
| If the above change causes a warning in a client code, so much the
| better: the client code is doing something unreasonable like the "*s"
| assignment in my example above.
,--- Robert Haas (Tue, 13 Dec 2011 10:51:54 -0500) ----*
| Or they just haven't bothered to decorate their entire code-base with
| const declarations.
They don't have to, for the conceptually correct code. I.e. one can
write (with the old and new code):
/* no: const */ PGresult *res; const char *readout; readout = PQxxx(res,...); /* no: *readout = 'x'; */
all right and have no compilation warnings.
But one can also (reasonably) const-qualify the 'res' above
(const-correct and const-consistent code is a good thing.)
| If you want this patch to be considered for application, you should
| post an updated patch which includes the necessary doc changes and add
| a link to it here:
|
| https://commitfest.postgresql.org/action/commitfest_view/open
OK, I could do it...
,--- Alvaro Herrera (Tue, 13 Dec 2011 13:01:13 -0300) ----*
| Do we really need a 100% complete patch just to discuss whether we're
| open to doing it? IMHO it makes sense to see a WIP patch and then
| accept or reject based on that; if we accept the general idea, then a
| complete patch would presumably be submitted.
`---------------------------------------------------------*
... but I like this more.
I.e., can one tell me to bother or not with the complete patch, based
on the general idea, which wouldn't change for the complete patch?
-- Alex -- alex-goncharov@comcast.net --
