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

From Dave Page
Subject Re: [pgadmin-hackers] Client-side password encryption
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4E7EB03@ratbert.vale-housing.co.uk
Whole thread Raw
List pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 19 December 2005 15:00
> To: Martijn van Oosterhout
> Cc: Dave Page; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
> encryption
>
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > 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...
>
> Surely that cure is far worse than the disease.  You'd be trading a
> might-break risk (app using new function will fail if used with old
> library) for a guaranteed-to-break risk (*every* app fails if used
> with *any* library version other than what it was built against).

If it's changed to include the so version, or PG version in the filename
(eg. Libpq41.dll, or libpq82.dll) then all we require is that a vendor
ship the appropriate version with his app. If it installs in a shared
location, it's guaranteed to only be upgraded by a point release because
the windows installers have no convention for including version numbers
in the filenames and will only upgrade a file of the name name, and with
an older version number (from the version resource).

Regards, Dave.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [pgadmin-hackers] Client-side password encryption
Next
From: "Luke Lonergan"
Date:
Subject: Re: Re: Which qsort is used