Hi, Kuroda-san, Fujii-san
I agree that this feature is useful. Thanks for working this.
I've tried to use the patches and read them. I have some questions.
1)
Why does postgres_fdw.application_name override the server's option?
> + establishes a connection to a foreign server. This overrides
> + <varname>application_name</varname> option of the server object.
> + Note that change of this parameter doesn't affect any existing
> + connections until they are re-established.
My expected behavior was that application_name option of server object
overrides the GUC because other GUCs seems behave so. For example,
log_statement in postgresql.conf can be overrided by ALTER ROLE for
only specific user. Should the narrower scope setting takes precedence?
2)
Is it better to specify that we can use the escaped format
for application_name option of the server object in the document?
I think it's new feature too.
3)
Is the following expected behavior?
* 1. [coorinator] configure "postgres_fdw.application_name" as "[%d]".
* 2. [coodinator] connect *Non-ASCII* database.
* 3. [coodinator] execute queries for remote server.
* 4. [remote] execute the following query.
```
postgres(2654193)=# SELECT application_name FROM pg_stat_activity WHERE
backend_type = 'client backend' ;
application_name
---------------------------
psql
[?????????]
```
One of the difference between log_line_prefix and application_name
is that whether it only allow clean ASCII chars or not. So, the above
behavior is expected.
I think there are three choices for handling the above case.
1) Accept the above case because Non-ASCII rarely be used(?), and
describe the limitation in the document.
2) Add a new characters for oid of database.
3) Lease the limitation of application_name and make it accept
Non-ASCII.
As a user, 3) is best for me.
But it seems be out of scope this threads, so will you select 1)?
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION