On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa <a...@8kdata.com> wrote: > LOL. Do you really want a half-baked Java programmer writing a patch in > C for PostgreSQL? I once tried that and Magnus said my code was Java code > that happened to compile with a C compiler.... ^_^ > > Having said that, I take the bait, I like challenges and putting my > words behind my code :)
Excellent, because that's how stuff gets done around here. Saying that you want something and hoping other people will do it is fine, but being will to put some effort into it is a lot more likely to get it done. Not to be harsh, but showing up 3 days after feature freeze to complain that a feature pending commit for 14 months is missing something that you really need isn't really the right way to make something happen. I'm pretty sure that the lack of channel binding was discussed quite a bit earlier than now, so I think there was adequate opportunity to protest, contribute a patch, etc. It's not that I don't have sympathy for the way you feel about this: seeing features you care about fall out of a release sucks, and I've experienced a lot of that suckage quite recently, so the pain is fresh in my mind. But it's something we all have to live with for the overall good of the product. We used to not have a firm feature freeze, and that was way worse. In this case, I think it is abundantly clear that SCRAM without channel binding is still a good feature. One piece of evidence for that is that the standard uses the suffix -PLUS to denote the availability of channel binding. That clearly conveys that channel binding has value, but also that not having it does not make the whole thing useless. Otherwise, they would have required it to be part of every implementation, or they would have made you add -CRAPPY if you didn't have it. The discussion elsewhere on this thread has adequately underlined the value of what we've already got, so I won't further belabor the point here. Furthermore, I think that the state of this feature as it currently exists in the tree is actually kind of concerning. There are currently four open items pertaining to SCRAM at least two of which look to my mind an awful lot like stuff that should have ideally been handled pre-feature-freeze: \password support, and protocol negotiation. I'm grateful for the hard work that has gone into this feature, but these are pretty significant loose ends. \password support is a basic usability issue. Protocol negotiation affects anyone who may want to make their PG driver work with this feature, and certainly can't be changed after final release, and ideally not even after beta. We really, really need to get that stuff nailed down ASAP or we're going to have big problems. So I think we should focus on those things, not this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
