SEO

#1 (**permalink**) 04-11-2008, 07:23 AM

> -----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.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

#2 (**permalink**) 04-11-2008, 07:23 AM

On Mon, Dec 19, 2005 at 09:16:19AM -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.

> > If programs are really worried about it, they should lookup the
> > function dynamically rather than statically...
>
> For the sake of a simple name change?

The function as stated above doesn't exist yet, so we're adding a new
function, not changing the name of one. The function that started the
thread is not even exported by libpq so changing that shouldn't affect
anybody. Besides, this whole discussion is moot until someone writes
such a function.

As for Windows DLL hell, I don't know a lot about that, but if that's
such a problem, why didn't the original creators of the windows port
stick the version number in there from the start. On UNIX, libpq is
half versioned (the library is, but not the symbols) so I would have
thought copying that idea would have been obvious.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDpn9YIB7bNG8LQkwRAqiZAJ4ijU42e+/eJipqTFmQYLxG4KAykgCeKACE
82dVohebwerzrUtvvezTPAo=
=98QE
-----END PGP SIGNATURE-----

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: [pgadmin-hackers] Client-side password encryption