On Tue, Aug 7, 2018 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> But having said that, I don't exactly see why you couldn't force it >> with an ultimately-redundant SetConfigOption call to put the value >> in place before the ereport happens. The GUC machinery is surely >> functional before we do authorization.
> If that's the approach you think makes the most sense, I wouldn't object > to it. I will point out that we'd end up with the application name in > the log line if it's also included in log_line_prefix, but that's what > happens with "user" anyway, isn't it?, so that doesn't seem to be a big > deal. I do think it's still good to have appplication_name explicitly > in the log message for users who want to just log application_name on > connection and not have it on every single log line.
Well, if you're going to insist on that part, it's probably not worth making the application_name GUC have inconsistent behavior.
regards, tom lane
OK so just to make sure I understand:
1. We want to make a generic, central ascii-lobotomizing function similar to check_application_name that we can re-use there and for other checks (eg user name).
2. Change check_application_name to call this function (or just call this function instead of check_application_name()?)
3. Call this function when storing the value in the port struct.
Please let me know if I'm missing/misunderstanding anything.
