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:

Previous
From: "Dave Cramer"
Date:
Subject: Re: JDBC driver
Next
From: "Dave Cramer"
Date:
Subject: Re: JDBC Connection