From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Client application name |
Date: | 2009-10-21 16:27:43 |
Message-ID: | 29394.1256142463@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dave Page <dpage(at)pgadmin(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-10-21 16:28:29 | Re: URL Managment - C Function help |
Previous Message | David E. Wheeler | 2009-10-21 16:24:20 | Re: Could regexp_matches be immutable? |