| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Dave Page <dpage(at)pgadmin(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Application name patch - v2 |
| Date: | 2009-10-19 14:49:13 |
| Message-ID: | 5229.1255963753@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2009-10-19 14:54:39 | Re: Controlling changes in plpgsql variable resolution |
| Previous Message | Dave Page | 2009-10-19 14:44:58 | Re: Application name patch - v2 |