Robert Haas <robertmh...@gmail.com> writes: > On point #2, I don't personally know of any systems that I care about > where inlining isn't supported. However, we've gone to quite a bit of > trouble relatively recently to keep things working for platforms where > that is the case, so I feel the need for an obligatory disclaimer: I > will not commit any patch that moves the wood in that area unless > there is massive consensus that this is an acceptable way forward. > Similarly for point #3: Heikki not long ago went to the trouble of > unbreaking --disable-spinlocks, which suggests that there is at least > some interest in continuing to be able to run in that mode. I'm > perfectly OK with the decision that we don't care about that any more, > but I will not be the one to make that decision, and I think it > requires a greater-than-normal level of consensus.
Hm. Now that I think about it, isn't Peter proposing to break systems without working "inline" over here? http://www.postgresql.org/message-id/1384257026.8059.5.ca...@vanquo.pezone.net Maybe that patch needs a bit more discussion. I tend to agree that significantly moving our portability goalposts shouldn't be undertaken lightly. On the other hand, it is 2013, and so it seems not unreasonable to reconsider choices last made more than a dozen years ago. Here's an idea that might serve as a useful touchstone for making choices: compiler inadequacies are easier to fix than hardware/OS inadequacies. Even a dozen years ago, people could get gcc running on any platform of interest, and I seriously doubt that's less true today than back then. So if anyone complains "my compiler doesn't support 'const'", we could reasonably reply "so install gcc". On the other hand, if the complaint is "my hardware doesn't support 64-bit CAS", it's not reasonable to tell them to buy a new server. 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
