From: Tom Lane on
"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes:
> Magnus Hagander <magnus(a)hagander.net> wrote:
>> For java, it doesn't even go through libpq, so it wouldn't be set
>> for it. And I'd expect the JDBC driver to set it based on Something
>> Reasonable (TM) that it can get the information about. After all,
>> this thing was listed in the JDBC spec somebody said...

> I can't see a good way to get a meaningful default from within the
> bowels of the JDBC driver, unless it's taking a system property or
> environment variable.

[ scratches head... ] I thought the JDBC spec already said exactly how
one would set this. Why would we go to significant effort to make it
behave contrary to spec?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on
Tom Lane <tgl(a)sss.pgh.pa.us> wrote:

> [ scratches head... ] I thought the JDBC spec already said exactly
> how one would set this. Why would we go to significant effort to
> make it behave contrary to spec?

We certainly should allow it to be set as specified in the spec. The
only question is whether it makes sense to provide a non-null default
if it is not set in that way. I thought Magnus was arguing for that.
I have no objection, and see potential use-cases where that would be
convenient.

To illustrate what I'm talking about, adding something like this to
the command line which starts Java would provide the non-null default:

-DPGAPPNAME="Receipting - Traffic"

(or whatever name we choose for this in place of PGAPPNAME.)
This seems similar to what is proposed for libpq.

The effort to support that would not be significant -- something
along the order of

if (appName == NULL)
appName = System.getProperty("PGAPPNAME");

Do you object?

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes:
> (or whatever name we choose for this in place of PGAPPNAME.)

FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
Dave has been using in his examples. The latter is too frickin
long, and the double N is a typo threat (I already mistyped it in
composing this message...)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on


Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes:
>
>> (or whatever name we choose for this in place of PGAPPNAME.)
>>
>
> FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
> Dave has been using in his examples. The latter is too frickin
> long, and the double N is a typo threat (I already mistyped it in
> composing this message...)
>
>
>

Well, the latter argument suggests we should use an underscore ...

We don't usually use abbreviations, so how about PGCLIENTNAME or some such?

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Andrew Dunstan <andrew(a)dunslane.net> writes:
> Tom Lane wrote:
>> FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what

> We don't usually use abbreviations, so how about PGCLIENTNAME or some such?

Not sure I believe that argument. Among the set of existing libpq
environment variables I see

PGHOSTADDR
PGSSLCERT
PGSSLCRL
PGKRBSRVNAME
PGTZ
PGSYSCONFDIR

so it can hardly be said that there's a policy of avoiding
abbreviations. PGCLIENTNAME would be better than PGAPPLICATIONNAME
I guess, but I still prefer the other.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 4 5 6 7 8 9 10 11 12 13 14 15
Prev: Hot standby status
Next: per table random-page-cost?