Обсуждение: 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. +
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
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
> 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. + 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>