Re: MD5-based passwords

From: Barry Lind <barry(at)xythos(dot)com>
To: Dave(at)micro-automation(dot)net
Cc: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "'psql-jdbc'" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: MD5-based passwords
Date: 2001-11-09 03:46:36
Message-ID: 3BEB519C.5030401@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

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(at)postgresql(dot)org
> [mailto:pgsql-jdbc-owner(at)postgresql(dot)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.
>
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Barry Lind 2001-11-09 03:49:35 Re: ResultSet.getDate failure with timestamp column
Previous Message Barry Lind 2001-11-09 03:31:23 Re: MD5-based passwords