Re: MD5-based passwords

Поиск
Список
Период
Сортировка
От Barry Lind
Тема Re: MD5-based passwords
Дата
Msg-id 3BEB519C.5030401@xythos.com
обсуждение исходный текст
Ответ на Re: MD5-based passwords  ("Dave Cramer" <Dave@micro-automation.net>)
Ответы Re: MD5-based passwords
Список 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@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 по дате отправления:

Предыдущее
От: Anil Jangam
Дата:
Сообщение: Re: [CYGWIN] PostgreSQL on cygwin
Следующее
От: Barry Lind
Дата:
Сообщение: Re: ResultSet.getDate failure with timestamp column