Robert Haas <robertmh...@gmail.com> wrote: > 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. The patch attached to Thomas's original post is an example of what I consider low-hanging fruit worth going after. It applies cleanly, causes no new warnings, and adds no new objects -- it just clarifies the API. (It was in checking for new warnings that I found the one I mentioned in the other post.) > 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. Well, nobody is asking you to do so. Thomas said that he was looking for something to do which would lead him through the code so he could learn it. > 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. If Thomas wants to do this as an exercise in learning PostgreSQL code, it seems like a win/win to me. We get minor clarifications of our APIs and another person with some understanding of the code base. > The kicker is that it's a lot of work for an unbelievably tiny > benefit, sometimes a negative benefit. Assuming duplicate declarations with and without const are off the table, where do you see the negative? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
