On 2015-07-02 11:46:25 -0400, Robert Haas wrote: > In the case of static inline, the main problem with the status quo > AFAICS is that you have to do a little dance any time you'd otherwise > use a static inline function (for those following along at home, "git > grep INCLUDE_DEFINITIONS src/include" to see how this is done). > Now, > it is obviously the case that the first time somebody has to do this > dance, they will be somewhat inconvenienced, but once you know how to > do it, it's not incredibly complicated.
I obviously know the schema (having introduced it in pg), but I think the costs are actually rather significant. It makes development more complex, it makes things considerably harder to follow, and it's quite annoying to test (manually redefine PG_USE_INLINE, recompile whole tree). Several times people also argued against using inlines with that trick because it's slowing down older platforms. > So, just to play the devil's advocate here, who really cares? I consider our time one of the most scarce resources around. > I'd consider an argument for adopting one of these features to be much > stronger if were accompanied by arguments like: > > - If we require feature X, we can reduce the size of the generated > code and improve performance. Converting some of the bigger macros (I tested fastgetattr) to inliens, actually does both. See also http://archives.postgresql.org/message-id/4407.1435763473%40sss.pgh.pa.us Now, all that is possible with the INCLUDE_DEFINITIONS stuff, but it makes it considerably more expensive time/complexity wise. > If everybody else here says "working around the lack of feature X is > too much of a pain in the butt and we want to adopt it purely too make > development easier", I'm not going to sit here and try to fight the > tide. But I personally don't find such arguments all that exciting. I find that an odd attitude. > I think // comments are a not something we should adopt, because one > style is better than two I don't particularly care about // comments either. They do have the advantage of allowing three more characters of actual content in one line comments ... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers