Tom Lane <t...@sss.pgh.pa.us> wrote: > I don't doubt that just duplicating macros and inlineable > functions is a wash performance-wise (in fact, in principle it > shouldn't change the generated code at all). I had the impression that compilers these days could sometimes better optimize across calls to functions with const parameters, because previously-referenced elements of the structures could be trusted to be unchanged across the call. I'm not talking about calls to the inlineable function or macros themselves, but the higher level functions which can then use const. > My objection is the one Robert already noted: it takes extra brain > cells to remember which function/macro to use, and I have seen not > a shred of evidence that that extra development/maintenance effort > will be repaid. Well, for me at least, seeing a parameter flagged as const helps me be sure that it will be use only for input to the function, and thus more quickly grasp the semantics of the API. For someone who is already familiar with an API, I doubt it helps much; and it may be one of those cognitive differences that just exist between people. As far as which to use when there is a const and a non-const version -- how is that unclear? For me it seems intuitively obvious (although perhaps my intuition is off-base) that I would use const when I didn't want the called function to change what was pointed at by the parameter. Maybe you're looking at the slippery slope more than this one function and two macros, though. > In C, the impedance match is a lot worse, so you have to pick and > choose where const is worth the trouble. Agreed. And I'm not sure how much of what Thomas is proposing is worth it; it just seems prudent to consider it while the offer is being made to do the work. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers