Why do we have a database specification in .pgpass?
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On 10/13/2010 02:32 PM, Bruce Momjian wrote:
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.
If you use wildcards for some of the other params it could well be useful.
cheers
andrew
Excerpts from Bruce Momjian's message of mié oct 13 15:32:22 -0300 2010:
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.
I think when I wrote it, I was hoping that the db_user_namespace thing
would be changed into a real per-database user implementation. That
would have meant having different passwords depending on the database.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.
There is the GUC parameter db_user_namespace. Just for that you could
probably use dennis@foo as username instead, so maybe it's not the
purpose. But I can't think of any other reason.
/Dennis
Hello, Bruce.
You wrote:
BM> We have a database specification in .pgpass:
BM> hostname:port:database:username:password
BM> What is the purpose of 'database' since username/password combinations
BM> are global, not per database? I would like to documents its purpose.
BM> --
BM> Bruce Momjian <bruce@momjian.us> http://momjian.us
BM> EnterpriseDB http://enterprisedb.com
BM> + It's impossible for everything to be true. +
For future use?
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com
On Thu, Oct 14, 2010 at 06:09:35AM +0200, Dennis Bj??rklund wrote:
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.There is the GUC parameter db_user_namespace. Just for that you could
probably use dennis@foo as username instead, so maybe it's not the
purpose. But I can't think of any other reason./Dennis
This will allow the same user to save and use automatically different
passwords for each separate database.
Cheers,
Ken
On ons, 2010-10-13 at 14:32 -0400, Bruce Momjian wrote:
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.
As a side note, the thing at the other end of a connection is not
necessarily a PostgreSQL server. It could be a connection pool proxy.
I don't know if any implementatation could make use of the database
field at the moment, but it should be kept in mind.
That said, it would probably be good to document that the database field
is currently only useful in certain limited circumstances.
Peter Eisentraut wrote:
On ons, 2010-10-13 at 14:32 -0400, Bruce Momjian wrote:
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.As a side note, the thing at the other end of a connection is not
necessarily a PostgreSQL server. It could be a connection pool proxy.
I don't know if any implementatation could make use of the database
field at the moment, but it should be kept in mind.That said, it would probably be good to document that the database field
is currently only useful in certain limited circumstances.
Agreed, done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
/rtmp/difftext/x-diffDownload
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 70d9202..a911c50 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** myEventProc(PGEventId evtId, void *evtIn
*** 6331,6336 ****
--- 6331,6338 ----
or the default socket directory) connections coming from the local
machine. In a standby server, a database name of <literal>replication</>
matches streaming replication connections made to the master server.
+ The <literal>database</> field is of limited usefulness because
+ users have the same password for all databases in the same cluster.
</para>
<para>