,--- 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-goncha...@comcast.net --

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to