On Wed, Jun 22, 2011 at 12:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Tue, Jun 21, 2011 at 5:51 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
