Re: Application name patch - v2

On Mon, Oct 19, 2009 at 3:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> I do agree with Peter's concerns about limiting the character set of the
>>> name string, and maybe there should be some sort of length limit too.
>
>> I was thinking we might just declare it of type 'name'..
>
> 'name' wouldn't help, since it's pretty character-set-agnostic.
> Anyway this is a GUC not a table column.

As a sidenote, in the stats part of this patch I did limit the length
to NAMEDATALEN for the purposes of sizing the shared memory
allocation, however it's otherwise unlimited in length. Practically
that just means that like the current query, the application name may
be truncated when viewed through pg_stat_get_activity().

> Thinking about it more, it should be sufficient if we can ensure that
> the value is in the database encoding; logging of statements will
> already cause pretty much any legal DB-encoded string to be written to
> the log, so if you have a problem with that then you've already got
> a problem to fix.

Right - that's what I was saying to Peter earlier. That can of course
be turned off though

> This is no issue for an ordinary SET, but AFAIR we do not have a good
> story for handling non-ASCII stuff arriving within the initial
> connection request packet.  It might be time to try to do something
> about that.  Or we could just restrict those values to ASCII.

It would seem sensible to apply the same rule to the connection string
and SET, if only for consistency (at least as far as application_name
is concerned). I know that use of Japanese/Chinese characters in
database names is not uncommon however, so restricting connection
strings to ASCII in general might not go down well.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com