Re: MD5-based passwords - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | Re: MD5-based passwords |
Date | |
Msg-id | 01e501c168d3$452d0110$c201a8c0@inspiron Whole thread Raw |
In response to | Re: MD5-based passwords (Barry Lind <barry@xythos.com>) |
List | pgsql-jdbc |
Barry, Yes, you are probably correct, poor choice of words. I did commit it earlier this evening; mainly because there is another related patch which has been stalled due to this section of the code changing so quickly. Dave -----Original Message----- From: Barry Lind [mailto:barry@xythos.com] Sent: November 8, 2001 10:47 PM To: Dave@micro-automation.net Cc: 'Bruce Momjian'; 'psql-jdbc' Subject: Re: MD5-based passwords Dave, I think it would make people feel better to say that you are going to 'apply some bug fixes that have been contributed' instead of saying 'I am going to add some of the code that has been contributed'. The latter makes it sound like new functionality, when in reality this patch mostly fixes bugs (with a little code refactoring thrown in for good measure). I think you should go ahead and apply this. This area of the code didn't work at all in 7.1, partly works in 7.2beta2, and I think will mostly work for 7.2.0 with this set of fixes. thanks, --Barry Dave Cramer wrote: > Ok, > > Thanks for all the input, I think at this point I am going to add some > of the code that has been contributed > None of it changes the drivers core behaviour. > > Specifically it is Jason Davies updates to the DatabaseMetaData > getImported/Exported keys > > Dave > > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Bruce Momjian > Sent: November 8, 2001 9:13 PM > To: Justin Clift > Cc: Tom Lane; Ned Wolpert; psql-jdbc > Subject: Re: [JDBC] MD5-based passwords > > > >>>Also, if the code proves to have bugs, what's the downside? Only >>> > that > >>>JDBC users will be unable to use MD5 passwords; but that will >>> > certainly > >>>be true if we don't try. So I think I'd go for it. >>> >>>On the other hand, some of the other stuff Dave mentioned sounded >>> > like > >>>whole new features, and since we are in beta now I think the "no new >>>features during beta" rule ought to apply. >>> >>I believe we should include the new stuff, as it would assist in the >> > 7.2 > >>release having more of an "Enterprise" functionality level than >>without. Might as well have MD5 all round. >> >>If bugs are found during our beta testing process, then it might delay >>the release for a week or two, which is probably worth it. >> > > I can say pretty reliably that we are long past time in 7.2 where we can > add code that will push back a final release date. It is fine to slip > stuff in and take the responsibility for it, but we are in beta now and > anything that pushes back final is bad, because it pushes back _all_ 7.2 > features from the general user community. > > Thinking of it another way, the value of any single feature can not > possibly be large compared to all the new features in 7.2 already. If > we add code now, patch appliers have to be willing to take the heat if > the patch delays final release. > > Now, of course I myself am applying stuff, but if it delays final, I > have failed and must take the responsibility for it. This is probably > the biggest difference between patch application during development > cycle and final. During development, patches are applied if they look > good and no one complains. During beta, responsibility lies solely with > the patch applier. > > Of course, you can patch things up during 7.2.X, and this often happens. > >
pgsql-jdbc by date: