Michael Fuhr <[EMAIL PROTECTED]> 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.)
Comments anyone?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
