On Mon, Oct 19, 2009 at 3:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> * Tom Lane (t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
