,--- 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: http://www.postgresql.org/mailpref/pgsql-hackers
