> > On May 15, 2008, at 6:31 AM, [EMAIL PROTECTED] wrote: > >>> Mark Woodward wrote: >>>> I am using PostgreSQL's SSL support and the conventions for the >>>> key and >>>> certifications don't make sense from the client perspective. >>>> Especially >>>> under Windows. >>>> >>>> I am proposing a few simple changes: >>>> >>>> Adding two API >>>> void PQsetSSLUserCertFileName(char *filename) >>>> { >>>> user_crt_filename = strdup(filename); >>>> } >>>> PQsetSSLUserKeyFileName(char *filename) >>>> { >>>> user_key_filename = strdup(filename); >>>> } >>>> >>>> >>>> >>> [snip] >>>> Any comments? >>>> >>>> >>> >>> >>> I think it would probably be much better to allow for some >>> environment >>> variables to specify the locations of the client certificate and key >>> (and the CA cert and CRL) - c.f. PGPASSFILE. >>> >>> That way not only could these be set by C programs but by any libpq >>> user >>> (I'm sure driver writers who use libpq don't want to have to bother >>> with >>> this stuff.) And we wouldn't need to change the API at all. >>> >> >> The problem I have with environment variables is that they tend not >> to be >> application specific and almost always lead to configuration issues. >> As a >> methodology for default configuration, it adds flexibility. Also, the >> current configuration does not easily take in to consideration the >> idea >> that different databases with different keys can be used from the same >> system the same user. > > Environment variables don't have to be set in your shell. > > This would seem to give the same functionality you suggest above, > given support for environment variables: > > void PQsetSSLUserCertFileName(char * filename) > { > setenv("PGCERTFILE", filename); > } > > void PQsetSSLUserKeyFileName(char *filename) > { > setenv("PGKEYFILE", filename); > } > > Or, in perl, $ENV{PGKEYFILE} = $file and so on. It seems > less intrusive than adding new API calls. > > Cheers, > Steve
Doesn't it make sense that the connection be configured in one place? I agree with Tom, if it should be done, it should be done in PQconnectdb. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers