pgsql: Instead of sending application_name as a SET command after the

Поиск
Список
Период
Сортировка
От tgl@postgresql.org (Tom Lane)
Тема pgsql: Instead of sending application_name as a SET command after the
Дата
Msg-id 20091202043835.C56BE753FB7@cvs.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Log Message:
-----------
Instead of sending application_name as a SET command after the connection
is made, include it in the startup-packet options.  This makes it work more
like every other libpq connection option, in particular it now has the same
response to RESET ALL as the rest.  This also saves one network round trip
for new applications using application_name.  The cost is that if the server
is pre-8.5, it'll reject the startup packet altogether, forcing us to retry
the entire connection cycle.  But on balance we shouldn't be optimizing that
case in preference to the behavior with a new server, especially when doing
so creates visible behavioral oddities.  Per discussion.

Modified Files:
--------------
    pgsql/src/interfaces/libpq:
        fe-connect.c (r1.380 -> r1.381)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-connect.c?r1=1.380&r2=1.381)
        fe-protocol3.c (r1.39 -> r1.40)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-protocol3.c?r1=1.39&r2=1.40)
        libpq-int.h (r1.145 -> r1.146)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq-int.h?r1=1.145&r2=1.146)

В списке pgsql-committers по дате отправления:

Предыдущее
От: fxjr@pgfoundry.org (User Fxjr)
Дата:
Сообщение: npgsql - Npgsql2: Fixed a bug where Npgsql wasn't honoring the
Следующее
От: tgl@postgresql.org (Tom Lane)
Дата:
Сообщение: pgsql: Mark application_name as GUC_REPORT so that the value will be