From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Client application name |
Date: | 2009-10-15 14:28:27 |
Message-ID: | 28928.1255616907@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dave Page <dpage(at)pgadmin(dot)org> writes:
> a) Added PQsetdbLogin2() with an additional option for the application
> name (my guess is 'no').
> b) Updated the apps to use PQconnectdb
> c) Something else?
a) is absolutely right out. b) is okay from an overall viewpoint but
you would find yourself doing something very much like this:
http://archives.postgresql.org/message-id/3073cc9b0909141123s7ec779a0h6524ec90a0a81c7@mail.gmail.com
So I would suggest
d) leave the issue unsolved until some descendant of that patch gets
committed, and then use it.
There is also
e) do nothing, since the environment var and SET options are plenty.
Also, I am wondering exactly what you think psql would *do* with the
parameter if it had it. If the answer is "force the setting to be
'psql'", that's the wrong answer. IMO you'd really want the environment
variable to take precedence over that, if set. But libpq considers the
priority to go the other way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-15 14:36:54 | Re: Trigger with WHEN clause (WIP) |
Previous Message | Euler Taveira de Oliveira | 2009-10-15 14:22:42 | Re: Client application name |