> 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:robertmhaas@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.kapila@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