Re: [PATCH] Include application_name in "connection authorized" log message

Greetings,

* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
> On 02.07.18 15:12, Don Seiler wrote:
> > On Mon, Jul 2, 2018 at 2:13 AM, Peter Eisentraut
> > <peter(dot)eisentraut(at)2ndquadrant(dot)com
> > <mailto:peter(dot)eisentraut(at)2ndquadrant(dot)com>> wrote:
> >
> > On 21.06.18 16:21, Don Seiler wrote:
> > > -                                               (errmsg("connection
> > > authorized: user=%s database=%s",
> > > -                                                             
> > >  port->user_name, port->database_name)));
> > > +                                               (errmsg("connection
> > > authorized: user=%s database=%s application=%s",
> > > +                                                             
> > >  port->user_name, port->database_name, port->application_name)));
> >
> > Why is it "application" and not "application_name"?
> >
> >
> > I was trying to be consistent since we don't use "user_name" or
> > "database_name" as labels even though those are the variable names.
>
> "user" and "database" are the keys used in the startup packet.

There's a good deal lacking here when it comes to consistency- the
string that users actually use most (the libpq connection string)
requires the database to be specified as 'dbname', not 'database', for
example.

Still, what's specified in the libpq connection string is
'application_name' and that's what the GUC is, and what's in the startup
packet, so it seems like we could at least be consistent with that.

Don, do you want to update the patch accordingly? If not, I'm happy to
handle it when I go to commit it, which I'm thinking of doing sometime
this weekend as it seems to be pretty uncontroversial at this point.

As an independent patch, it might be nice to have libpq accept
'database' in place of 'dbname' and update the docs to recommend that,
and maybe then even have a 'database' read-only GUC, and maybe a 'user'
one too (though it looks like we might have to hack the grammar some to
get that to work cleanly...), just to move things to be more consistent
across the board. That's all very clearly independent from this patch
though.

Thanks!

Stephen