Re: pg_service.conf ignores dbname parameter

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mfuhr(at)fuhr(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_service.conf ignores dbname parameter
Date: 2003-12-17 17:39:02
Message-ID: 8467.1071682742@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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.)

Comments anyone?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-12-17 17:42:54 Re: BUG #1009: ERROR: could not open segment 1 of relation...
Previous Message Mark Shewmaker 2003-12-17 16:59:39 SELECT FOR UPDATE differs inside and outside a pl/pgsql function (7.4)

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-12-17 17:51:24 Re: [HACKERS] pg_service.conf ignores dbname parameter
Previous Message Andrew Dunstan 2003-12-17 17:12:11 Re: [PATCHES] Double Backslash example patch