Folks,

It doesn't appear that the JDBC driver knows about pg_service.conf.
If that's so, would it be a big challenge to add that feature?

Thanks in advance for any hints, tips, pointers, &c.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

david@fetter.org (David Fetter) wrote:
> Folks,
>
> It doesn't appear that the JDBC driver knows about pg_service.conf.
> If that's so, would it be a big challenge to add that feature?
>
> Thanks in advance for any hints, tips, pointers, &c.

Yeah, that would be a pretty slick thing.

We're starting to look at this; using it initially so DBA accounts
only need one PG value set to get psql to work.

It's *tempting* to use pg_service.conf to control Slony-I. There's a
fragility to it in that pg_service.conf has to be kept consistent on
all the relevant servers, although that would normally be just one
server per site...

..pgpass support is under way, right? That's better than
pg_service.conf :-).
--
"cbbrowne","@","gmail.com"
http://linuxfinances.info/info/finances.html
"It don't mean a thing, if it ain't got that swing..."

David,

Can you give us the use case? How would you expect this to work ?

Dave
On 13-Mar-06, at 10:23 PM, David Fetter wrote:

> Folks,
>
> It doesn't appear that the JDBC driver knows about pg_service.conf.
> If that's so, would it be a big challenge to add that feature?
>
> Thanks in advance for any hints, tips, pointers, &c.
>
> Cheers,
> D
> --
> David Fetter david@fetter.org http://fetter.org/
> phone: +1 415 235 3778
>
> Remember to vote!
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Mon, Mar 13, 2006 at 11:11:43PM -0500, Dave Cramer wrote:
> David,
>
> Can you give us the use case? How would you expect this to work ?

Let's imagine you have a pg_service.conf that says:

[foo]
host=foo.example.com
dbname=foo
port=5555
user=dcramer

[bar]
host=bar.example.com
dbname=bar
port=5554
user=dfetter

[baz]
host=baz.sample.com
dbname=baz
port=5553
user=brass_monkey

You'd use a connect string that looked something like

jdbcostgresql://service=foo/

to get to the db called foo running foo.example.com on port 5555 as
ROLE (aka user) dcramer. The pg_service.conf could then be
distributed around and available to every kind of application--even
ones not written in java.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, Mar 13, 2006 at 10:57:03PM -0500, Christopher Browne wrote:
> david@fetter.org (David Fetter) wrote:
> > Folks,
> >
> > It doesn't appear that the JDBC driver knows about
> > pg_service.conf. If that's so, would it be a big challenge to add
> > that feature?
> >
> > Thanks in advance for any hints, tips, pointers, &c.
>
> Yeah, that would be a pretty slick thing.
>
> We're starting to look at this; using it initially so DBA accounts
> only need one PG value set to get psql to work.

That would be a Very Good Thing(TM)

> It's *tempting* to use pg_service.conf to control Slony-I. There's
> a fragility to it in that pg_service.conf has to be kept consistent
> on all the relevant servers, although that would normally be just
> one server per site...

That's true.

> .pgpass support is under way, right? That's better than
> pg_service.conf :-).

They shouldn't be mutually exclusive

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

David.

OK, so as I understand it the client would be responsible for
finding, parsing this file and reading the appropriate section.

Assuming the PGSYSCONFDIR environment variable is setup properly and
the driver has access to the file this would work.

This would be a lot easier if the server managed this file.

Dave
On 14-Mar-06, at 12:30 AM, David Fetter wrote:

> On Mon, Mar 13, 2006 at 11:11:43PM -0500, Dave Cramer wrote:
>> David,
>>
>> Can you give us the use case? How would you expect this to work ?
>
> Let's imagine you have a pg_service.conf that says:
>
> [foo]
> host=foo.example.com
> dbname=foo
> port=5555
> user=dcramer
>
> [bar]
> host=bar.example.com
> dbname=bar
> port=5554
> user=dfetter
>
> [baz]
> host=baz.sample.com
> dbname=baz
> port=5553
> user=brass_monkey
>
> You'd use a connect string that looked something like
>
> jdbcostgresql://service=foo/
>
> to get to the db called foo running foo.example.com on port 5555 as
> ROLE (aka user) dcramer. The pg_service.conf could then be
> distributed around and available to every kind of application--even
> ones not written in java.
>
> Cheers,
> D
> --
> David Fetter david@fetter.org http://fetter.org/
> phone: +1 415 235 3778
>
> Remember to vote!
>


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

In the last exciting episode, pg@fastcrypt.com (Dave Cramer) wrote:
> David.
>
> OK, so as I understand it the client would be responsible for
> finding, parsing this file and reading the appropriate section.
>
> Assuming the PGSYSCONFDIR environment variable is setup properly and
> the driver has access to the file this would work.
>
> This would be a lot easier if the server managed this file.

Unfortunately, that represents a recursive need. pg_service.conf is
used to determine where the server might be, so you need to read it
before you can know where the server is...

Note that libpq takes the perspective that pg_service.conf should live
in the ../etc directory for the PostgreSQL build. Thus, if psql is
living as /opt/dbs/pgsql825/bin/psql, then this would be in
/opt/dbs/pgsql825/etc/pg_service.conf.
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/rdbms.html
linux: the choice of a GNU generation
(ksh@cis.ufl.edu put this on Tshirts in '93)

Ever wanted to retract an email after you sent it ? I realized the
complete stupidity of that statement 30 seconds after I hit send

Dave
On 14-Mar-06, at 7:51 AM, Christopher Browne wrote:

> In the last exciting episode, pg@fastcrypt.com (Dave Cramer) wrote:
>> David.
>>
>> OK, so as I understand it the client would be responsible for
>> finding, parsing this file and reading the appropriate section.
>>
>> Assuming the PGSYSCONFDIR environment variable is setup properly and
>> the driver has access to the file this would work.
>>
>> This would be a lot easier if the server managed this file.
>
> Unfortunately, that represents a recursive need. pg_service.conf is
> used to determine where the server might be, so you need to read it
> before you can know where the server is...
>
> Note that libpq takes the perspective that pg_service.conf should live
> in the ../etc directory for the PostgreSQL build. Thus, if psql is
> living as /opt/dbs/pgsql825/bin/psql, then this would be in
> /opt/dbs/pgsql825/etc/pg_service.conf.
> --
> let name="cbbrowne" and tld="cbbrowne.com" in String.concat
> "@" [name;tld];;
> http://linuxdatabases.info/info/rdbms.html
> linux: the choice of a GNU generation
> (ksh@cis.ufl.edu put this on Tshirts in '93)
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly
>


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Christopher Browne wrote:

> Note that libpq takes the perspective that pg_service.conf should live
> in the ../etc directory for the PostgreSQL build. Thus, if psql is
> living as /opt/dbs/pgsql825/bin/psql, then this would be in
> /opt/dbs/pgsql825/etc/pg_service.conf.

The big thing here is "how do we find the config file?". The JDBC driver
has no concept of an "installation" .. it's just classes that the JVM
manages to load somehow.

-O

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

In an attempt to throw the authorities off his trail, pg@fastcrypt.com (Dave Cramer) transmitted:
> Ever wanted to retract an email after you sent it ? I realized the
> complete stupidity of that statement 30 seconds after I hit send

Well, this is a common enough problem that there are occasions where
people build server-based mechanisms for it...

Oracle has something whose name I misremember where you head to a
server to get the *real* server configuration.

CORBA had this notion with the Naming Service; you start by getting a
connection to a Naming Service object, and then ask where the *real*
services are...

How to do it "right" for JDBC is a good question. Searching for
..pgpass in $HOME is pretty obvious. It is less obvious where to
search for pg_service.conf if all that is installed is JDBC, and there
is no PostgreSQL instance around.
--
output = reverse("gro.mca" "@" "enworbbc")
http://linuxdatabases.info/info/internet.html
What do you mean "Why's it got to be built?" It is a bypass. You've got
to build bypasses.