Dave Page <dp...@pgadmin.org> writes: > On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Hmm. Maybe this is a generic problem. Should libpq offer some sort >> of help? Maybe a "secondaryappname" parameter that doesn't override >> the env variable.
> is it worth uglifying libpq? All we're talking about is something like: > if (!getenv("PGAPPLICATIONNAME")) > strncat(connstr, " application_name=psql", sizeof(connstr) - > strlen(connstr) - 1); Well, per earlier discussion we're not really interested in doing this with connection strings, it's going to be some sort of parameter array deal. This approach might require a read-write instead of constant parameter array (depending on how the other patch eventually works out). But the main thing that's bugging me about it is the explicit knowledge on the application's part that there is an environment variable that interacts with this setting. Seems ugly and badly-factored. Another possibility that should be mentioned for the record is that we could special-case the appname parameter inside libpq, so that the environment variable takes precedence over the conn setting instead of the other way round. That seems pretty ugly too, but maybe it's the least bad answer, if we decide that most apps need that precedence. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers