Docs for service file

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

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