Andrew Gierth <and...@tao11.riddles.org.uk> writes: > "Thomas" == Thomas Munro <thomas.mu...@enterprisedb.com> writes: > Thomas> -1 for making superficial changes to code that we are > Thomas> "vendoring", unless it is known to be dead/abandoned and we're > Thomas> definitively forking it. It just makes it harder to track > Thomas> upstream's bug fixes and improvements, surely?
> Well, the question there is how far to take that principle; do we avoid > pgindent'ing the code, do we avoid changing uint64_t etc. to uint64 > etc., and so on. > The Ryu code is perhaps an extreme example because it follows almost the > exact reverse of our coding standard. My heart kind of sinks when looking at this patch, because it's a large addition of not-terribly-well-documented code that nobody here really understands, never mind the problem that it's mostly not close to our own coding standards. Our track record in borrowing code from "upstream" projects is pretty miserable: almost without exception, we've found ourselves stuck with maintaining such code ourselves after a few years. I don't see any reason to think that wouldn't be true here; in fact there's much more reason to worry here than we had for, eg, borrowing the regex code. The maintenance track record of this github repo appears to span six months, and it's now been about four months since the last commit. It might be abandonware already. Is this a path we really want to go down? I'm not convinced the cost/benefit ratio is attractive. If we do go down this path, though, I'm not too worried about making it simple to absorb upstream fixes; I bet there will be few to none. (Still, you might want to try to automate and document the coding format conversion steps, along the line of what I've done recently for our copy of tzcode.) regards, tom lane