From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dave Page <dpage(at)pgadmin(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Client application name |
Date: | 2009-10-21 18:06:39 |
Message-ID: | 603c8f070910211106q66ed8a77h236e980eaa05fb82@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-10-21 18:37:57 | Re: Controlling changes in plpgsql variable resolution |
Previous Message | Josh Berkus | 2009-10-21 17:59:21 | Re: Controlling changes in plpgsql variable resolution |