Re: SVN Commit by guillaume: r8145 - in trunk/pgadmin3: . pgadmin/db pgadmin/frm
От | Guillaume Lelarge |
---|---|
Тема | Re: SVN Commit by guillaume: r8145 - in trunk/pgadmin3: . pgadmin/db pgadmin/frm |
Дата | |
Msg-id | 4B3B524D.7090306@lelarge.info обсуждение исходный текст |
Ответ на | Re: SVN Commit by guillaume: r8145 - in trunk/pgadmin3: . pgadmin/db pgadmin/frm (Dave Page <dpage@pgadmin.org>) |
Ответы |
Re: SVN Commit by guillaume: r8145 - in
trunk/pgadmin3: . pgadmin/db pgadmin/frm
|
Список | pgadmin-hackers |
Le 30/12/2009 13:53, Dave Page a écrit : > Sorry - I didn't get a chance to actually look at this patch until now. > Oops, sorry. I try not to be too quick, but as you already answered on this patch... > The application_name should be set as a connection string parameter, > not an explicit SET command. That was the first thing I wanted to do. But people won't be able to use pgAdmin with older PostgreSQL releases if we use the connection string parameter. Or we have to attempt a first connection with it, and if that one fails, drop the application name in the connection string. I don't think we should bother with this. It adds error messages on old releases. I much prefer the explicit SET command approach. > This ensures that the application name is > included in the initial connection log message, and avoids a round > trip with the SET query. PQconninfoParse can be used to test if libpq > supports application_name at runtime. > I don't understand that. libpq and the server are two different things. You can have a new libpq on your client and an old server. client's PQconninfoParse will tell you application_name is available, but it could be that the server doesn't understand it. Perhaps I need to get a better look at PQconninfoParse, but don't have the time right now. > I suspect the patch is also missing some changes to the debugger. > Probably, I'll look at this. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
В списке pgadmin-hackers по дате отправления: