Re: [pgadmin-hackers] Client-side password encryption - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [pgadmin-hackers] Client-side password encryption
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE6C7D9A@algol.sollentuna.se
Whole thread Raw
Responses Re: [pgadmin-hackers] Client-side password encryption  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
> > > 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.
> >
> > Because we simply didn't think of it at the time, and it's
> something
> > that has irked me ever since.
>
> In that case, I agree. I've always thought a lot of problem
> in windows could be solved if they systematically added a
> version number to every library (like in UNIX).
>
> Are there any reasons why we shouldn't change the libname
> with every release like for UNIX? I can't think of any, but
> you never know...

Yes.
If FooApp is compiled against 8.0, it will then be unable to run if you
upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new
version if it's just a minor version upgrade (correct me if I'm wrong).
On windows, it will break with an ugly dialog box. Which is why DLL
renames are usually only done for backwards incompatible changes.

//Magnus


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Re: Which qsort is used
Next
From: Martijn van Oosterhout
Date:
Subject: Re: [pgadmin-hackers] Client-side password encryption