Robert Haas <robertmhaas@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