> That seems undesirable. I don't think this is important enough to be worth reparsing > the connection string for. The connect string should not be long, so parsing is not a big cost performance wise. I have currently modified the code for dblink in the patch I have uploaded in CF. However as per your suggestion, I will remove it during handling of other Review comments for patch unless somebody asks to keep it.
-----Original Message----- From: Robert Haas [mailto:robertmh...@gmail.com] Sent: Thursday, June 14, 2012 7:25 PM To: Amit Kapila Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila <amit.kap...@huawei.com> wrote: > >> Why not 'dblink'? > > We can do for dblink as well. I just wanted to check before implementing in > dblink. > > I have checked the dblink_connect() function, it receives the connect string > and used in most cases that string to > call libpq connect which is different from pgbench and oid2name where > connection parameters are formed in main function and then call libpq > connect. > > 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. -- 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
