On tis, 2012-01-10 at 14:10 -0500, Alex Goncharov wrote:
| Note that const PGresult * would only warn against changing the
| fields
It would not warn, it would err (the compilation should fail).
No, const violations generally only produce warnings.
| of the PGresult struct. It doesn't
On tis, 2011-12-13 at 07:55 -0500, Alex Goncharov wrote:
char *PQcmdStatus(PGresult *res);
char *PQcmdTuples(PGresult *res);
Unreasonable:
a. What, these two can modify 'res' I pass in?..
b. Oh, yes, because they return 'char *' pointing to
'res-cmdStatus+n', so, a libpq
,--- You/Peter (Tue, 10 Jan 2012 19:13:42 +0200) *
| On tis, 2011-12-13 at 07:55 -0500, Alex Goncharov wrote:
|char *PQcmdStatus(PGresult *res);
|char *PQcmdTuples(PGresult *res);
|
| Unreasonable:
|
|a. What, these two can modify 'res' I pass in?..
|
|b. Oh, yes,
Compare:
int PQntuples(const PGresult *res)
Reasonable: doesn't modify 'res'.
With:
char *PQcmdStatus(PGresult *res);
char *PQcmdTuples(PGresult *res);
Unreasonable:
a. What, these two can modify 'res' I pass in?..
b. Oh, yes, because they return 'char *' pointing to
On Tue, Dec 13, 2011 at 7:55 AM, Alex Goncharov
alex-goncha...@comcast.net wrote:
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.
Or they just haven't bothered to decorate
,--- 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
On Tue, Dec 13, 2011 at 11:01 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar dic 13 12:51:54 -0300 2011:
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
Excerpts from Alex Goncharov's message of mar dic 13 13:43:35 -0300 2011:
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?
So let's see the patch. In context diff format please, and also include
in-tree
Excerpts from Robert Haas's message of mar dic 13 12:51:54 -0300 2011:
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
