Re: libpq: PQcmdStatus, PQcmdTuples signatures can be painlessly improved

From: Alex Goncharov <alex-goncharov(at)comcast(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq: PQcmdStatus, PQcmdTuples signatures can be painlessly improved
Date: 2012-01-10 19:10:21
Message-ID: E1Rkh5R-000IlI-ES@hans3
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

,--- 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, because they return 'char *' pointing to
| > 'res->cmdStatus+n', so, a libpq user may write:
| >
| > char *s = PQcmdStatus(res);
| > *s = 'x';
| >
| > and have 'res' modified. (Would be the user's fault, of course.)
| >
| Note that const PGresult * would only warn against changing the
| fields

It would not warn, it would err (the compilation should fail).

| of the PGresult struct. It doesn't do anything about changing the data
| pointed to by pointers in the PGresult struct. So what you are saying
| doesn't follow.

By this logic, passing 'const struct foo *' doesn't have any point and
value, for any function. But we know that this is done (and thank you
for that) in many cases -- a good style, self-documentation and some
protection.

E.g. here:

,--- I/Alex (Tue, 13 Dec 2011 07:55:45 -0500) ----*
| Compare:
|
| int PQntuples(const PGresult *res)
|
| Reasonable: doesn't modify 'res'.
`-------------------------------------------------*

BTW, I have not submitted the context differences, as suggested, only
because of extreme overload at work and the need to do a careful
caller and documentation analysis. I still hope to be able to do it in
a reasonably near future.

-- Alex -- alex-goncharov(at)comcast(dot)net --

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2012-01-10 20:22:41 Re: random_page_cost vs seq_page_cost
Previous Message Pavel Stehule 2012-01-10 18:03:31 Re: Add SPI results constants available for PL/*