| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink |
| Date: | 2012-06-14 13:55:09 |
| Message-ID: | CA+TgmoajnavkPOxmpx4pFoYKpXVqF=aExUr2E=kR_EVSrzkm0A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2012-06-14 13:57:53 | Re: [PATCH 02/16] Add zeroRecPtr as a shortcut for initializing a local variable to {0, 0} |
| Previous Message | Robert Haas | 2012-06-14 13:50:28 | Re: [PATCH 02/16] Add zeroRecPtr as a shortcut for initializing a local variable to {0, 0} |