* Tom Lane ([EMAIL PROTECTED]) wrote:
> Right offhand I like the idea of pushing it into connectOptions2 --- can
> you experiment with that?  Seems like there is no reason to call
> Kerberos if the user supplies the name to connect as.

Patch attached.  After looking through the code around this I discovered
that conninfo_parse is also called by PQconndefaults.  This patch
changes the 'default' returned for user to NULL (instead of whatever
pg_fe_getauthname returns).  This is probably better than not calling
Kerberos in pg_fe_getauthname and potentially returning the wrong thing
(if the username doesn't match the princ, a common situation), but it
might break existing applications.  Are those applications wrong to be
asking libpq to provide what it thinks the username is when asking for
the defaults?  I'd say probably yes, but then we don't provide another
way for them to get it either.

Patch tested w/ 'trust', 'ident', 'md5' and 'krb5' methods from psql.

        Enjoy,

                Stephen
Index: src/interfaces/libpq/fe-connect.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.326
diff -c -r1.326 fe-connect.c
*** src/interfaces/libpq/fe-connect.c   13 Feb 2006 22:33:57 -0000      1.326
--- src/interfaces/libpq/fe-connect.c   15 Feb 2006 18:21:06 -0000
***************
*** 96,105 ****
   * fallback is available. If after all no value can be determined
   * for an option, an error is returned.
   *
-  * The value for the username is treated specially in conninfo_parse.
-  * If the Compiled-in resource is specified as a NULL value, the
-  * user is determined by pg_fe_getauthname().
-  *
   * The Label and Disp-Char entries are provided for applications that
   * want to use PQconndefaults() to create a generic database connection
   * dialog. Disp-Char is defined as follows:
--- 96,101 ----
***************
*** 423,434 ****
--- 419,448 ----
   *
   * Compute derived connection options after absorbing all user-supplied info.
   *
+  * The value for the username is treated specially in connectOptions2.
+  * If the Compiled-in resource is specified as a NULL value and the user
+  * doesn't provide a username to use then the user is determined by 
+  * calling pg_fe_getauthname().
+  *
   * Returns true if OK, false if trouble (in which case errorMessage is set
   * and so is conn->status).
   */
  static bool
  connectOptions2(PGconn *conn)
  {
+       char            errortmp[PQERRORMSG_LENGTH];
+ 
+       /*
+        * Find username to use if none given.  This may call
+        * additional helpers (ie: krb5) if those auth methods
+        * are compiled in.
+        */
+       if (conn->pguser == NULL || conn->pguser[0] == '\0')
+       {
+               conn->pguser = pg_fe_getauthname(errortmp);
+               /* note any error message is thrown away */
+       }
+ 
        /*
         * If database name was not given, default it to equal user name
         */
***************
*** 2505,2511 ****
        char       *cp2;
        PQconninfoOption *options;
        PQconninfoOption *option;
-       char            errortmp[PQERRORMSG_LENGTH];
  
        /* Make a working copy of PQconninfoOptions */
        options = malloc(sizeof(PQconninfoOptions));
--- 2519,2524 ----
***************
*** 2722,2737 ****
                        }
                        continue;
                }
- 
-               /*
-                * Special handling for user
-                */
-               if (strcmp(option->keyword, "user") == 0)
-               {
-                       option->val = pg_fe_getauthname(errortmp);
-                       /* note any error message is thrown away */
-                       continue;
-               }
        }
  
        return options;
--- 2735,2740 ----
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to