Dear Fujii-san,
Thank you for replying! I attached new version.
> Why did you make even %u and %d available in application_name?
Actually no particular reason. I added them because they can easily add...
And I agree what you say, so removed.
> So some people may want to specify their own ID in application_name
> when connecting to the foreign server. For now they can do that by
> setting application_name per foreign server object. But this means that
> every session connecting to the same foreign server basically should
> use the same application_name. If they want to change the setting,
> they need to execute "ALTER SERAVER ... OPTIONS ...". Isn't this inconvenient?
Yeah, currently such users must execute ALTER command for each time.
> If yes, what about allowing us to specify foreign server's application_name
> per session? For example, we can add postgres_fdw.application_name GUC,
> and then if it's set postgres_fdw always uses it instead of the server-level
> option when connecting to the foreign server. Thought?
OK, I added the GUC parameter. My patch Defines new GUC at _PG_init().
The value is used when backends started to connect to remote server.
Normal users can modify the value by SET commands but
that change does not propagate to the established connections.
I'm not sure about the versioning policy about contrib.
Do we have to make new version? Any other objects are not changed.
Finally, I and Fujii-san were now discussing locally whether
this replacement should be in libpq or postgres_fdw layer.
I started to think that it should be postgres_fdw, because:
* previously aplications could distinguish by using current applicaiton_name,
* libpq is used almost all uses so some modifications might affect someone, and
* libpq might be just a tool, and should not be intelligent
I will make and attach another version that new codes move to postgres_fdw.
So could you vote which version is better?
Best Regards,
Hayato Kuroda
FUJITSU LIMITED