> -----Original Message-----
> From: Martijn van Oosterhout [mailto:kleptog@svana.org]
> Sent: 19 December 2005 08:59
> To: Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
> encryption
>
> On Mon, Dec 19, 2005 at 08:51:23AM -0000, Dave Page wrote:
> > > Something like
> > > char *pg_gen_encrypted_passwd(const char *passwd, const
> > > char *user)
> > > with malloc'd result (or NULL on failure) seems more future-proof.
> >
> > Changing the API is likely to cause fun on Windows for new apps that
> > find an old libpq.dll. Perhaps at this point it should become
> > libpq82.dll?
>
> Hmm? Libpq already has a version number, I beleive it's upto 4.1 right
> now. So if any number is used, it should be that.
Good point
> And secondly, there
> have already been new functions added to the API without changing the
> library name so why should that happen here?
Because I suspect Tom hasn't suffered from 'dll hell' as a non-Windows
user, and because noone else noticed.
> In windows the trend seems to be to upgrade a library if the
> one on the
> system is too old.
Yes, however it's possible that there might be multiple copies of a dll
on a single system. The search order for the DLLs has changed over the
years and over different Windows versions though, so it's not infeasible
for an app to upgrade one copy, but then load a different one when it
runs. It shouldn't affect pgAdmin, psqlODBC or pgInstaller because we
keep the DLLs local to the .exe's which is always first in the search
path, but other apps might suffer.
> If programs are really worried about it,
> they should
> lookup the function dynamically rather than statically...
For the sake of a simple name change?
Regards, Dave.
