Обсуждение: Re: [JDBC] [HACKERS] PGSERVICEFILE as a connection string parameter

Поиск
Список
Период
Сортировка

Re: [JDBC] [HACKERS] PGSERVICEFILE as a connection string parameter

От
Andres Freund
Дата:
On 2017-02-27 16:23:46 +0100, Magnus Hagander wrote:
> On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote:
> > > I bumped into a case where it would have been rather useful to specify
> > > a service file path in a connection string with a service name. In my
> > > case, I have finished by setting up PGSERVICEFILE, but now like
> > > PGPASSFILE I think that being able to define the service file
> > > available as well as a connection parameter would be useful as well.
> > >
> > > I am not planning to work on that immediately (there is one day left
> > > for the last CF of PG10!), but I was wondering if people would be
> > > interested in something like that.
> >
> > Hm - I'm not sure that's a good idea. service files are a libpq feature,
> > but connection strings are a bit more universal than just libpq...
> >
>
> That same argument applies to PGPASSFILE, does it not?

It does.  I'm not really convinced it's a good idea to have that as a
full blown parameter, but as you say:

> Properly implementing PGSERVICEFILE is more complicated though -- as it
> requires LDAP support to go there the whole way for example.



> But it might not hurt to encourage other drivers (such as jdbc) to
> support at least the basic format of pgpass.

Probably makes sense to bring in some of the external driver authors
(jdbc, npgsql CCed).

Greetings,

Andres Freund


Re: [HACKERS] PGSERVICEFILE as a connection string parameter

От
Dave Cramer
Дата:
+Vladimir

On 27 February 2017 at 11:36, Andres Freund <andres@anarazel.de> wrote:
On 2017-02-27 16:23:46 +0100, Magnus Hagander wrote:
> On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote:
> > > I bumped into a case where it would have been rather useful to specify
> > > a service file path in a connection string with a service name. In my
> > > case, I have finished by setting up PGSERVICEFILE, but now like
> > > PGPASSFILE I think that being able to define the service file
> > > available as well as a connection parameter would be useful as well.
> > >
> > > I am not planning to work on that immediately (there is one day left
> > > for the last CF of PG10!), but I was wondering if people would be
> > > interested in something like that.
> >
> > Hm - I'm not sure that's a good idea. service files are a libpq feature,
> > but connection strings are a bit more universal than just libpq...
> >
>
> That same argument applies to PGPASSFILE, does it not?

It does.  I'm not really convinced it's a good idea to have that as a
full blown parameter, but as you say:

> Properly implementing PGSERVICEFILE is more complicated though -- as it
> requires LDAP support to go there the whole way for example.



> But it might not hurt to encourage other drivers (such as jdbc) to
> support at least the basic format of pgpass.

Probably makes sense to bring in some of the external driver authors
(jdbc, npgsql CCed).

Currently PGPASS is in the users home directory Many JDBC applications are in much larger apps such as tomcat, etal
this concept is a bit foreign to JDBC. That being said I don't think it's difficult to implement. Just somewhat harder to specify
for us. psql is rather limited being a command line app which is *usually* evoked directly from the command line.


Re: [JDBC] [HACKERS] PGSERVICEFILE as a connection string parameter

От
Dave Cramer
Дата:
+Vladimir

On 27 February 2017 at 11:36, Andres Freund <andres@anarazel.de> wrote:
On 2017-02-27 16:23:46 +0100, Magnus Hagander wrote:
> On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote:
> > > I bumped into a case where it would have been rather useful to specify
> > > a service file path in a connection string with a service name. In my
> > > case, I have finished by setting up PGSERVICEFILE, but now like
> > > PGPASSFILE I think that being able to define the service file
> > > available as well as a connection parameter would be useful as well.
> > >
> > > I am not planning to work on that immediately (there is one day left
> > > for the last CF of PG10!), but I was wondering if people would be
> > > interested in something like that.
> >
> > Hm - I'm not sure that's a good idea. service files are a libpq feature,
> > but connection strings are a bit more universal than just libpq...
> >
>
> That same argument applies to PGPASSFILE, does it not?

It does.  I'm not really convinced it's a good idea to have that as a
full blown parameter, but as you say:

> Properly implementing PGSERVICEFILE is more complicated though -- as it
> requires LDAP support to go there the whole way for example.



> But it might not hurt to encourage other drivers (such as jdbc) to
> support at least the basic format of pgpass.

Probably makes sense to bring in some of the external driver authors
(jdbc, npgsql CCed).

Currently PGPASS is in the users home directory Many JDBC applications are in much larger apps such as tomcat, etal
this concept is a bit foreign to JDBC. That being said I don't think it's difficult to implement. Just somewhat harder to specify
for us. psql is rather limited being a command line app which is *usually* evoked directly from the command line.


Re: [JDBC] [HACKERS] PGSERVICEFILE as a connection string parameter

От
Vladimir Sitnikov
Дата:
David>I'm guessing that the Java port wouldn't be too
complicated.  It's already well defined.

Is encoding defined somewhere for the "service file"?
I don't like the idea of using "a default" very much.

Vladimir

Re: [JDBC] [HACKERS] PGSERVICEFILE as a connection string parameter

От
Vladimir Sitnikov
Дата:
David>I'm guessing that the Java port wouldn't be too
complicated.  It's already well defined.

Is encoding defined somewhere for the "service file"?
I don't like the idea of using "a default" very much.

Vladimir