Dave Page <dpage(at)pgadmin(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
On 12/1/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
> > On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I don't think that we need to bump the protocol version. The real
> >> alternative here would be that libpq sends a startup packet that
> >> includes application_name, and if it gets an error back from that,
> >> it starts over without the app name.
>
>
> > I looked (briefly) at doing that when we first ran into this
> > suggestion. As you pointed out at the time, it seemed like that would
> > require some fairly ugly hackery in fe-connect.c
>
>
> Perhaps, but at the time it wasn't apparent that issuing a separate SET
> would create user-visible behavioral inconsistencies. Now that we've
> realized that, I think we should reconsider.
>
> If people are agreed that double connect is a better alternative
> I'm willing to go look at how to make it happen.
Is it supposed to work with pooling or not?
If the pooler gets new connection with same username:database
as some existing connection, but with different appname,
what it is supposed to do?
--
marko