On Wed, Jun 27, 2012 at 9:57 PM, Shigeru HANADA <shigeru.han...@gmail.com> wrote: > On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila <amit.kap...@huawei.com> wrote: >>> To achieve the same in dblink, we need to parse the passed connection string >>> and check if it contains fallback_application_name, if yes then its okay, >>> otherwise we need to append fallback_application_name in connection string. >> >> That seems undesirable. I don't think this is important enough to be >> worth reparsing the connection string for. I'd just forget about >> doing it for dblink if there's no cheaper way. > > Indeed reparsing connection string is not cheap, but dblink does it for > checking password requirement for non-in dblink_connstr_check when the > local user was not a superuser. So Amit's idea doesn't seem > unreasonable to me, if we can avoid extra PQconninfoParse call. > > Just an idea, but how about pushing fallback_application_name handling > into dblink_connstr_check? We reparse connection string unless local > user was a superuser, so it would not be serious overhead in most cases. > Although it might require changes in DBLINK_GET_CONN macro...
*shrug* If it can be done without costing anything meaningful, I don't object, but I would humbly suggest that this is not hugely important one way or the other. application_name is primarily a monitoring convenience, so it's not hugely important to have it set anyway, and fallback_application_name is only going to apply in cases where the user doesn't care enough to bother setting application_name. Let's not knock ourselves out to solve a problem that may not be that important to begin with. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
