On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote:
> 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
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
