On Wed, Nov 9, 2011 at 10:45 AM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Perhaps there should be a few more 'XXX_const' accessor function >>> variants, for example list_nth_const, >> >> This is exactly what was bothering Robert and me about Peter's >> patch.If you go down this road you soon start needing duplicate >> functions for no other reason than that one takes/returns "const" >> and one doesn't. > > What about existing functions which are not intended to modify their > inputs, don't actually do so, and can be marked to indicate that > just by adding "const" to the current declarations? Aside from any > possible value in code optimization by the compiler, I find it helps > me understand unfamiliar code more quickly, by making the contract > of the API more explicit in the declaration. Perhaps it's worth > going after the low-hanging fruit?
My feeling is that there's no harm (and possibly some benefit) in const-ifying functions that do very simple things. But as soon as you get to functions where the const-ness starts growing all over the system like kudzu, it's time to run away screaming. Moreover, I don't really want to see us spend a lot of time figuring out exactly what we can or can't const-ify. I feel as virtuous as the next guy when I mark something const, but my experience over the years is that it rapidly turns a huge amount of work. That by itself is not enough reason not to do it; many worthwhile things are hard. The kicker is that it's a lot of work for an unbelievably tiny benefit, sometimes a negative benefit. -- 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
