Thread: Docs for service file
Here is documentation and a sample file for the libpq service/PGSERVICE
capabilithy we added in 2000. Seems it was never documented. It allows
a central file, pg_service.conf to act as a central location for service
information.
You do connectdb("service=test") and a lookup is done to see the
connection parameters. The code assume pg_service exists in
install_dir/etc. Not sure if that is the right place, but it is a libpq
config file, so none of the other places seemed to make sense. Ideas?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v
retrieving revision 1.104
diff -c -c -r1.104 libpq.sgml
*** doc/src/sgml/libpq.sgml 6 Jan 2003 22:48:16 -0000 1.104
--- doc/src/sgml/libpq.sgml 7 Jan 2003 04:06:52 -0000
***************
*** 1,5 ****
<!--
! $Header: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v 1.104 2003/01/06 22:48:16 momjian Exp $
-->
<chapter id="libpq">
--- 1,5 ----
<!--
! $Header: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v 1.103 2002/12/13 05:49:10 momjian Exp $
-->
<chapter id="libpq">
***************
*** 206,211 ****
--- 206,224 ----
Set to 1 to require SSL connection to the backend. <application>Libpq</>
will then refuse to connect if the server does not support
SSL. Set to 0 (default) to negotiate with server.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>service</literal></term>
+ <listitem>
+ <para>
+ Service name to use for additional parameters. It specifies a service
+ name in pg_service.conf that holds additional connection parameters.
+ This allows applications to specify only a service name so connection parameters
+ can be centrally maintained. See <literal>pg_service.conf.sample</> for
+ information on how to set up the file.
</para>
</listitem>
</varlistentry>
Index: src/backend/Makefile
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/Makefile,v
retrieving revision 1.90
diff -c -c -r1.90 Makefile
*** src/backend/Makefile 6 Jan 2003 03:18:26 -0000 1.90
--- src/backend/Makefile 7 Jan 2003 04:06:52 -0000
***************
*** 140,147 ****
> $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6
$(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 $(DESTDIR)$(datadir)/pg_hba.conf.sample
endif
$(INSTALL_DATA) $(srcdir)/libpq/pg_ident.conf.sample $(DESTDIR)$(datadir)/pg_ident.conf.sample
! $(INSTALL_DATA) $(srcdir)/utils/misc/postgresql.conf.sample $(DESTDIR)$(datadir)/postgresql.conf.sample
install-bin: postgres $(POSTGRES_IMP) installdirs
$(INSTALL_PROGRAM) postgres$(X) $(DESTDIR)$(bindir)/postgres$(X)
--- 140,148 ----
> $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6
$(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 $(DESTDIR)$(datadir)/pg_hba.conf.sample
endif
+ $(INSTALL_DATA) $(srcdir)/libpq/pg_service.conf.sample $(DESTDIR)$(datadir)/pg_service.conf.sample
$(INSTALL_DATA) $(srcdir)/libpq/pg_ident.conf.sample $(DESTDIR)$(datadir)/pg_ident.conf.sample
! $(INSTALL_DATA) $(srcdir)/utils/misc/postgresql.conf.sample $(DESTDIR)$(datadir)/postgresql.conf.sample
install-bin: postgres $(POSTGRES_IMP) installdirs
$(INSTALL_PROGRAM) postgres$(X) $(DESTDIR)$(bindir)/postgres$(X)
***************
*** 179,186 ****
endif
$(MAKE) -C catalog uninstall-data
rm -f $(DESTDIR)$(datadir)/pg_hba.conf.sample \
$(DESTDIR)$(datadir)/pg_ident.conf.sample \
! $(DESTDIR)$(datadir)/postgresql.conf.sample
##########################################################################
--- 180,188 ----
endif
$(MAKE) -C catalog uninstall-data
rm -f $(DESTDIR)$(datadir)/pg_hba.conf.sample \
+ $(DESTDIR)$(datadir)/pg_service.conf.sample \
$(DESTDIR)$(datadir)/pg_ident.conf.sample \
! $(DESTDIR)$(datadir)/postgresql.conf.sample
##########################################################################
Index: src/interfaces/libpq/fe-connect.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.218
diff -c -c -r1.218 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 6 Jan 2003 22:48:16 -0000 1.218
--- src/interfaces/libpq/fe-connect.c 7 Jan 2003 04:07:00 -0000
***************
*** 2338,2351 ****
return 1;
}
! /* As default, set the database name to the name of the service */
for (i = 0; options[i].keyword; i++)
if (strcmp(options[i].keyword, "dbname") == 0)
! {
! if (options[i].val != NULL)
! free(options[i].val);
! options[i].val = strdup(service);
! }
while ((line = fgets(buf, MAXBUFSIZE - 1, f)) != NULL)
{
--- 2338,2348 ----
return 1;
}
! /* If not already set, set the database name to the name of the service */
for (i = 0; options[i].keyword; i++)
if (strcmp(options[i].keyword, "dbname") == 0)
! if (options[i].val == NULL)
! options[i].val = strdup(service);
while ((line = fgets(buf, MAXBUFSIZE - 1, f)) != NULL)
{
#
# Connection configuration file
#
# A service is a set of named connection parameters. You may specify
# multiple services in this file. Each starts with a service name in
# brackets. Subsequent lines have connection configuration parameters of
# the pattern "param=value". A sample configuration for template1 is
# included in this file. If no database name is specified, it is assumed
# to match the service name. Lines beginning with '#' are comments.
#
# Copy this to your sysconf directory (typically /usr/local/pgsql/etc) and
# rename it pg_service.conf.
#
#
#[template1]
#user=postgres
Bruce Momjian writes: > Here is documentation and a sample file for the libpq service/PGSERVICE > capabilithy we added in 2000. Seems it was never documented. The reason it was never documented is that the patch was slipped in without much discussion and several people were unsure whether the feature should exist in the first place, so as long as it isn't documented it doesn't really exist. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Here is documentation and a sample file for the libpq service/PGSERVICE > > capabilithy we added in 2000. Seems it was never documented. > > The reason it was never documented is that the patch was slipped in > without much discussion and several people were unsure whether the feature > should exist in the first place, so as long as it isn't documented it > doesn't really exist. Oh, that was it. Yuck. Well, it seems like a nifty features. What do others think? It allows centralized connection parameters. I don't particularly like the file format, but I think it was done to match Oracle. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Well, it seems like a nifty features. What do others think? It allows
> centralized connection parameters.
It seems quite bogus to me: what good is a configuration file on the
server machine to clients on other machines? (And if it's not on the
server, one can hardly call it centralized.)
A proper design for such a feature would pass the service name as part
of the startup packet and let the postmaster fill in missing fields
using a server-side config file. Then it would be useful for local
and remote clients alike.
Rather than documenting it and thereby locking ourselves into a
misdesigned "feature", I'd vote for removing code and docs too.
We can put the concept on the TODO-for-protocol-change list instead.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Well, it seems like a nifty features. What do others think? It allows > > centralized connection parameters. > > It seems quite bogus to me: what good is a configuration file on the > server machine to clients on other machines? (And if it's not on the > server, one can hardly call it centralized.) It is centralized in the sense the all clients can read the same local file. You can change the port number in one location rather than editing all your code, though we do have environment variables that do the same thing, though you can't really have the app choosing the environment variables. > A proper design for such a feature would pass the service name as part > of the startup packet and let the postmaster fill in missing fields > using a server-side config file. Then it would be useful for local > and remote clients alike. I don't see how that would work because you can put port numbers and host names in there. > Rather than documenting it and thereby locking ourselves into a > misdesigned "feature", I'd vote for removing code and docs too. > We can put the concept on the TODO-for-protocol-change list instead. Again, not sure if that is feasable. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote: > Rather than documenting it and thereby locking ourselves into a > misdesigned "feature", I'd vote for removing code and docs too. > We can put the concept on the TODO-for-protocol-change list instead. Other votes? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Tom Lane wrote: > >>Rather than documenting it and thereby locking ourselves into a >>misdesigned "feature", I'd vote for removing code and docs too. >>We can put the concept on the TODO-for-protocol-change list instead. > > > Other votes? It seems like we're talking about two slightly different features: a) A centralised file on a local machine that local client apps can use to co-ordinate port numbers and similar through, and b) A "service name" that works across-the-wire. Oracle has something like this, and has a "service name lookup daemon" thing in place that remote clients can connect to through TCP in order to find out the necessary parameters for connecting to a particular service. We should probably clarify a bit more on things before starting into voting. :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Justin Clift wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > >>Rather than documenting it and thereby locking ourselves into a > >>misdesigned "feature", I'd vote for removing code and docs too. > >>We can put the concept on the TODO-for-protocol-change list instead. > > > > > > Other votes? > > It seems like we're talking about two slightly different features: > > a) A centralised file on a local machine that local client apps can use > to co-ordinate port numbers and similar through, and Yes, this is the current functionality. > b) A "service name" that works across-the-wire. Oracle has something > like this, and has a "service name lookup daemon" thing in place that > remote clients can connect to through TCP in order to find out the > necessary parameters for connecting to a particular service. > > We should probably clarify a bit more on things before starting into voting. It seems strange how you would know where to get that connection info. I guess it could be used by just specifying the port number and host name, and some daemon would listen and set params. That seems too involved to me, though. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: <snip> >>b) A "service name" that works across-the-wire. Oracle has something >>like this, and has a "service name lookup daemon" thing in place that >>remote clients can connect to through TCP in order to find out the >>necessary parameters for connecting to a particular service. >> >>We should probably clarify a bit more on things before starting into voting. > > > It seems strange how you would know where to get that connection info. > I guess it could be used by just specifying the port number and host > name, and some daemon would listen and set params. That seems too > involved to me, though. Well, from memory the Oracle service name listener thing can be setup to hold information about instances of oracle databases (services) on many different servers, with whatever connection info is needed. Equivalent functionality for us would be something like: PG Service Name daemon IP = 192.168.10.100, TCP = something Holding info about: Service name: Primary1 IP = 192.168.10.1, TCP = 5432, db name = foo Service name: Primary2 IP = 192.168.10.10, TCP = 5432, db name = foo2 Service name: Dev1 IP = 192.168.10.2, TCP = 5432, db name = dev1 Service name: Dev2 IP = 192.168.10.2, TCP = 5432, db name = dev2 Service name: Dev3 IP = 192.168.10.2, TCP = 5433, db name = dev3 Service name: Dev4 IP = 192.168.10.3, TCP = 5432, db name = dev2b Service name: Dev5 IP = 192.168.10.3, TCP = 5433, db name = dev3b So, remote clients are configured to connect to the PG Service Name daemon first in order to find out where their desired database is, etc. Not sure how other DB systems do this kind of thing, this example is just one part of how Oracle does it's service name resolution stuff. :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Oh, so there is one central server with connection information. Interesting. Might be easier to just NFS mount the pg_service.conf file on all the machines.... at least easier for us. ;-) --------------------------------------------------------------------------- Justin Clift wrote: > Bruce Momjian wrote: > <snip> > >>b) A "service name" that works across-the-wire. Oracle has something > >>like this, and has a "service name lookup daemon" thing in place that > >>remote clients can connect to through TCP in order to find out the > >>necessary parameters for connecting to a particular service. > >> > >>We should probably clarify a bit more on things before starting into voting. > > > > > > It seems strange how you would know where to get that connection info. > > I guess it could be used by just specifying the port number and host > > name, and some daemon would listen and set params. That seems too > > involved to me, though. > > Well, from memory the Oracle service name listener thing can be setup to > hold information about instances of oracle databases (services) on many > different servers, with whatever connection info is needed. > > Equivalent functionality for us would be something like: > > PG Service Name daemon > IP = 192.168.10.100, TCP = something > > Holding info about: > > Service name: Primary1 > IP = 192.168.10.1, TCP = 5432, db name = foo > > Service name: Primary2 > IP = 192.168.10.10, TCP = 5432, db name = foo2 > > Service name: Dev1 > IP = 192.168.10.2, TCP = 5432, db name = dev1 > > Service name: Dev2 > IP = 192.168.10.2, TCP = 5432, db name = dev2 > > Service name: Dev3 > IP = 192.168.10.2, TCP = 5433, db name = dev3 > > Service name: Dev4 > IP = 192.168.10.3, TCP = 5432, db name = dev2b > > Service name: Dev5 > IP = 192.168.10.3, TCP = 5433, db name = dev3b > > So, remote clients are configured to connect to the PG Service Name > daemon first in order to find out where their desired database is, etc. > > Not sure how other DB systems do this kind of thing, this example is > just one part of how Oracle does it's service name resolution stuff. > > :-) > > Regards and best wishes, > > Justin Clift > > -- > "My grandfather once told me that there are two kinds of people: those > who work and those who take the credit. He told me to try to be in the > first group; there was less competition there." > - Indira Gandhi > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Oh, so there is one central server with connection information. > Interesting. Might be easier to just NFS mount the pg_service.conf file > on all the machines.... at least easier for us. ;-) Heh Heh Heh Yep, probably. ;-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Bruce Momjian wrote: > Oh, so there is one central server with connection information. > Interesting. Might be easier to just NFS mount the pg_service.conf file > on all the machines.... at least easier for us. ;-) > The way this is used on Oracle (at least in my experience) is to distribute a "tnsnames.ora" file to all of your client machines. Our Oracle dba maintains a master copy in cvs, and distributes changes whenever he adds or moves an Oracle instance (equiv to a single PostgreSQL database). It's a pain to keep the file syncronized, but it is nice to be able to able to type "prod" or "proto" or whatever depending on the database you want to connect to, without having to remember the actual server name and port. I have never actually seen the Oracle Names Listener (i.e the central service info server) functionality used (even though we have it). Not sure why. Joe
Joe Conway wrote: > Bruce Momjian wrote: > > Oh, so there is one central server with connection information. > > Interesting. Might be easier to just NFS mount the pg_service.conf file > > on all the machines.... at least easier for us. ;-) > > > > The way this is used on Oracle (at least in my experience) is to distribute a > "tnsnames.ora" file to all of your client machines. Our Oracle dba maintains a > master copy in cvs, and distributes changes whenever he adds or moves an > Oracle instance (equiv to a single PostgreSQL database). > It's a pain to keep the file syncronized, but it is nice to be able to able to > type "prod" or "proto" or whatever depending on the database you want to > connect to, without having to remember the actual server name and port. You need to use NFS readonly mounts. So it seems you use something almost identical to our client-side pg_service.conf file in Oracle. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
While we are arguing about whether this patch deserves to live or not,
may I point out that CVS tip is broken?
make[3]: Leaving directory `/home/postgres/pgsql/src/backend/catalog'
grep -v '^host.*::1.*ffff:ffff:ffff:ffff:ffff:ffff' \
./libpq/pg_hba.conf.sample \
> ./libpq/pg_hba.conf.sample.no_ipv6
/bin/sh ../../config/install-sh -c -m 644 ./libpq/pg_hba.conf.sample.no_ipv6
/home/postgres/testversion/share/pg_hba.conf.sample
/bin/sh ../../config/install-sh -c -m 644 ./libpq/pg_service.conf.sample
/home/postgres/testversion/share/pg_service.conf.sample
install: ./libpq/pg_service.conf.sample does not exist
make[2]: *** [install] Error 1
make[2]: Leaving directory `/home/postgres/pgsql/src/backend'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/postgres/pgsql/src'
make: *** [install] Error 2
regards, tom lane
Sorry, I thought I had added that. Done. --------------------------------------------------------------------------- Tom Lane wrote: > While we are arguing about whether this patch deserves to live or not, > may I point out that CVS tip is broken? > > > make[3]: Leaving directory `/home/postgres/pgsql/src/backend/catalog' > grep -v '^host.*::1.*ffff:ffff:ffff:ffff:ffff:ffff' \ > ./libpq/pg_hba.conf.sample \ > > ./libpq/pg_hba.conf.sample.no_ipv6 > /bin/sh ../../config/install-sh -c -m 644 ./libpq/pg_hba.conf.sample.no_ipv6 /home/postgres/testversion/share/pg_hba.conf.sample > /bin/sh ../../config/install-sh -c -m 644 ./libpq/pg_service.conf.sample /home/postgres/testversion/share/pg_service.conf.sample > install: ./libpq/pg_service.conf.sample does not exist > make[2]: *** [install] Error 1 > make[2]: Leaving directory `/home/postgres/pgsql/src/backend' > make[1]: *** [install] Error 2 > make[1]: Leaving directory `/home/postgres/pgsql/src' > make: *** [install] Error 2 > > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes: > Tom Lane wrote: > > Rather than documenting it and thereby locking ourselves into a > > misdesigned "feature", I'd vote for removing code and docs too. > > We can put the concept on the TODO-for-protocol-change list instead. > > Other votes? I'm still looking for a reason to use this feature. Clearly, as it stands it is only single-host. And on a single host you can use the environment variables. Also, any reasonable application provides its own way to encapsulate database connection information. And the other emails don't convince me at all that this is somehow "Oracle-compatible". Maybe you want to use ODBC, which gives you something like this and much more. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Tom Lane wrote: > > > Rather than documenting it and thereby locking ourselves into a > > > misdesigned "feature", I'd vote for removing code and docs too. > > > We can put the concept on the TODO-for-protocol-change list instead. > > > > Other votes? > > I'm still looking for a reason to use this feature. Clearly, as it stands > it is only single-host. And on a single host you can use the environment > variables. Also, any reasonable application provides its own way to > encapsulate database connection information. And the other emails don't > convince me at all that this is somehow "Oracle-compatible". > > Maybe you want to use ODBC, which gives you something like this and much > more. Joe Conway says he uses this exact feature in Oracle. They just distribute the file to the hosts. That seemed like a good reason to keep it. Obviously the original patch submitter liked it too. I think the nice thing was that you can just call the service name and get some params. It seems better to do that than try to switch to the proper environment variables before starting the app. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes: > Joe Conway says he uses this exact feature in Oracle. They just > distribute the file to the hosts. That seemed like a good reason to > keep it. OK, if we're keeping it then let's at least get things right. The documentation doesn't contain any information about the file format. It refers you to a file called pg_service.conf.sample for more information. The information should be moved from the file to the documentation. Also, the documentation doesn't give any hint where that file is supposed to be. Also, the sample file really belongs in src/include/libpq in the source tree. -- Peter Eisentraut peter_e@gmx.net
I will work on this. I didn't document the format of the services file in SGML because I wanted to make it as small as possible in the docs, because it has a small target audience. However, if you want the docs to be in SGML, I will do that. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > Joe Conway says he uses this exact feature in Oracle. They just > > distribute the file to the hosts. That seemed like a good reason to > > keep it. > > OK, if we're keeping it then let's at least get things right. The > documentation doesn't contain any information about the file format. It > refers you to a file called pg_service.conf.sample for more information. > The information should be moved from the file to the documentation. Also, > the documentation doesn't give any hint where that file is supposed to be. > > Also, the sample file really belongs in src/include/libpq in the source > tree. > > -- > Peter Eisentraut peter_e@gmx.net > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
OK, I have moved the file to interfaces/libpq. I will add some documentation, and probably update the file format to be more unix-like. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > Joe Conway says he uses this exact feature in Oracle. They just > > distribute the file to the hosts. That seemed like a good reason to > > keep it. > > OK, if we're keeping it then let's at least get things right. The > documentation doesn't contain any information about the file format. It > refers you to a file called pg_service.conf.sample for more information. > The information should be moved from the file to the documentation. Also, > the documentation doesn't give any hint where that file is supposed to be. > > Also, the sample file really belongs in src/include/libpq in the source > tree. > > -- > Peter Eisentraut peter_e@gmx.net > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I specified the file path better in the docs; don't think it makes sense to push the file format docs into the SGML because it is not a feature that is going to be used very much. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > Joe Conway says he uses this exact feature in Oracle. They just > > distribute the file to the hosts. That seemed like a good reason to > > keep it. > > OK, if we're keeping it then let's at least get things right. The > documentation doesn't contain any information about the file format. It > refers you to a file called pg_service.conf.sample for more information. > The information should be moved from the file to the documentation. Also, > the documentation doesn't give any hint where that file is supposed to be. > > Also, the sample file really belongs in src/include/libpq in the source > tree. > > -- > Peter Eisentraut peter_e@gmx.net > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073