Andres Freund <and...@anarazel.de> writes: > At the very least I think we should start to rely on 'static inline's > working. There is not, and hasn't been for a while, any buildfarm animal > that does not support it
pademelon doesn't. Also, I think there are some other non-gcc animals that nominally allow "static inline" but will generate warnings when such functions are unreferenced in a particular compile (that's what the "quiet inline" configure test is about). That would be hugely annoying for development, though maybe we don't care too much if it's only a build target. I'm not against requiring static inline; it would be a huge improvement really. But we should not fool ourselves that this comes at zero compatibility cost. > The list of features, in the order of perceived importance, that might > be worthwhile thinking about are: > * static inline > * variadic macros > * designated initializers (e.g. somestruct foo = { .bar = 3 } ) > * // style comments (I don't care, but it comes up often enough ...) Of these I think only the first is really worth breaking portability for. 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