On Wed, Jun 22, 2011 at 12:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Tue, Jun 21, 2011 at 5:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Declarations like "const structtype *param" are fine, because those
>>> create a real, enforced contract on what the function can do to data
>>> that is visible to its caller. But I don't see any value at all in
>>> const-ifying the parameter itself.
>
>> What about making a separate typedef for that (like ConstRelation)?
>
> Well, any change along this line would require pretty widespread
> changes, as you'd have to const-ify from the bottom up, or else hold
> your nose and cast-away-const in assorted calls (which I think is so
> evil you might as well not have the const in the first place).
>
> If we were thinking of moving in that direction, I would argue that
> we should get rid of typedef'd pointers altogether, ie, change
> "Relation" to be a typedef for the struct and write "Relation *rel"
> not "Relation rel". Then, attaching a const to the front is easy,
> natural, and does what the naive reader would expect. But this would
> be a sufficiently sweeping change that I'm not sure the benefits
> would be worth the cost.
I don't really see the point, either. I mean, the Relation is
basically a cache. And so it could happen that we want to start
caching something we don't cache today. Then someone for whom it was
const suddenly needs it to be non-const. Of course I don't think
there's much call for monkeying with rel->rd_id but how likely is that
to be a real source of coding errors?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
