On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote: > On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs <si...@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
This highlights a different issue. If you wish to pass arbitrary SET parameter(s) to a client then it is difficult to do so. We would be better off solving that generic problem than solving your specific one. Consider PGDEADLOCKTIMEOUT=1 pg_dump mydb PGWORKMEM=32657 psql < data.log Same requirement as setting the appname. Specific code for each parameter is the wrong way to do that. > 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. If they can use SET, why are we changing libpq? If we are changing libpq, why would we ignore those changes in the clients? (We don't need to change clients, but most clients expose some language specific feature to set things rather than just ignore them and let them be set via libpq). -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
