"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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?
I have no objection to const-ifying anything that can be done with one or two localized changes. The difficulty comes in when you try to make core infrastructure like expression_tree_walker do it. (And of course the problem then is that there are not so many functions that don't use any of that core infrastructure, so if you try to const-ify them you end up having to cast away const internally; which does not seem like a net advance to me.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers