On Tue, 14 Feb 2006, Stephen Frost wrote:
<snip>
> It's kind of a chicken-and-egg here because the backend decides what
> authentication mechanism to ask for based off the username (at least in
> part) through pg_hba.conf, so you can't find out the authentication
> method until you know the username so all methods to find the username
> have to be exhausted. You could avoid this by explicitly passing
> 'user=' into the connection parameters though... Would be interesting
> to know what happens then...
When asking about "explicitly passing 'user=' in to the connection
parameters" do you mean that the EXEC SQL CONNECT line that ecpg parses
should specify a username?
My code is using the following statement when making a remote connection
that uses SSL.
EXEC SQL CONNECT TO :l_target AS :l_connection
USER :l_user IDENTIFIED BY :l_passwd;
The target machine (hosting the database) has "ssl=on" in postgresql.conf
and in its pg_hba.conf (snippet below) a line for the client machine from
which I am making the connection that specifies an SSL connection should
be made.
# TYPE DATABASE USER CIDR-ADDRESS METHOD
hostssl andrew5 andrew5 172.19.130.4/32 pam passwd
--Andrew J. Klosterman
[EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
