Dear Ikeda-san, > I agree that this feature is useful. Thanks for working this.
Thanks :-). > 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? Hmm... I didn't know the policy in other options, thank you. I set higher priority because of the following reason. When users set app name as server option and create remote connection from same backend process, they will use same even if GUC sets. In this case users must execute ALTER SERVERS every session, and I think it is inconvenient. I think both approaches are reasonable, so I also want to ask committer. Fujii-san, how do you think? > 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. Yeah, I agree. I will add at `Connection Options` section in 0002 patch. Is it OK? Do we have more good place? > 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)? Actually I did not considering about such a situation... But I want to choose (1) because the limitation is caused by libpq layer and the modification is almost unrelated to this patch. I'm not sure why appname have such a limitation so at first we should investigate it. How do you think? Best Regards, Hayato Kuroda FUJITSU LIMITED
