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
Re: Client application name |
Список | 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 по дате отправления: