![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
|
Michael Fuhr <mfuhr (AT) fuhr (DOT) org> writes: When a client connects to the database server using a service name, the dbname parameter in pg_service.conf is ignored. In the absence of an explicitly-named database in the connection string, the service name is used as the database name regardless of that service's dbname setting. [snip] I haven't yet examined the rest of the code closely enough to come up with the correct patch, but it seems that the "set the database name to the name of the service" code should be deferred until after all of the service's parameters have been read. Hm. I'm of the opinion that the real problem here is the code's assumption that it is reasonable to force dbname = servicename when the service file doesn't say any such thing. For all other parameters, omitting the parameter from pg_service.conf causes the standard default to be adopted. Why should dbname work differently? It saves only a minimal amount of typing to do it this way, and it might prevent some useful setups (namely, a service that specifies connection params but allows the usual default of dbname = username to apply). Since pg_service was completely undocumented before 7.4, I think it is safe to say that its usage in the field is nil except for the original author, and therefore "backwards compatibility" is not really a relevant argument just yet. We ought to concentrate on "principle of least astonishment" instead. Accordingly, I'd rather just delete the offending code instead of move it. (BTW, I notice Bruce has fooled with this code before, so it's already in the "known source of problems" category.) |
![]() |
| Thread Tools | |
| Display Modes | |
| |