On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dave Page <dp...@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.
Are we really thinking about interposing an additional server round-trip on every connection for such a marginal feature (to paraphrase yourself)? That doesn't seem like a good trade-off. > 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. Either way, seems like you can try it with all the options and the back up one major release at a time until you find compatibility. It's only O(features), not O(2^features). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
