Re: Client application name

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Client application name
Дата
Msg-id 29394.1256142463@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Client application name  (Dave Page <dpage@pgadmin.org>)
Ответы Re: Client application name  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Client application name  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Dave Page <dpage@pgadmin.org> writes:
> BTW, any thoughts on Heikki's suggestions of hacking about the
> 'options' value or retrying the connection vs. just doing a SET
> post-connection in libpq? It's pretty certain that whatever I choose
> you probably won't like :-p

The post-connect SET still seems like the best choice to me.
It's mildly annoying that that won't help for log_connections
messages, but in the big scheme of things that's really not a
killer problem.

The retry approach is not too bad from a user perspective: it would
only actually happen during a server version mismatch, which isn't
*that* common.  My recollection though is that there's no graceful way
to implement a retry in libpq; you'd need a significant amount of new,
ugly, special-purpose code, with the complexity rising very fast if
there's more than one reason to retry.  If you can figure out a clean
implementation this one would be okay with me, but I'm dubious that
it's worth the work.

That options hack was just an ugly hack, I don't like it at all ---
mainly because I don't believe that approach scales to solve more
than one case either.
        regards, tom lane


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

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Could regexp_matches be immutable?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: URL Managment - C Function help