On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The SET seems sufficient for me. All interfaces currently support it.
SET alone will not allow what I see as one of the most useful uses of
this - consider:
PGAPPLICATIONNAME="Nightly backup" pg_dump mydb
PGAPPLICATIONNAME="Sensor data import" psql < data.log
> The reason we want this is because the app name is not available at
> connection time. It will only ever be NULL in the connection log
> messages in the cases where this is most needed. In other cases, the app
> name is not uniquely associated with a session and can change over time.
> What value is there in knowing the app name at connection? Could we not
> just log the app name iff log_connections is enabled?
It allows you to identify what application or script a connection came
from. Sure, you can probably figure that out regardless (from PID and
later log messages for example), but it's convenient and avoids the
need to correlate multiple log entries to one another.
> Also, adding something to libpq means we have to alter all the clients
> and that means they become incompatible with earlier versions. What
> advantage comes from doing all of that work? Nothing even close to large
> enough to warrant the pain and delay, AFAICS.
I must be missing something - why do we have to alter the clients? As
it stands, they can use SET with whatever libpq they currently have,
however if they wish to use the environment or connection string
they'll need to update to the new libpq version. Those apps that don't
care won't be affected because the libpq API hasn't changed in any way
that isn't fully backwards compatible.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start