Re: Application name patch - v2 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Application name patch - v2
Date
Msg-id 603c8f070910190840h3d036671scc22e52d22fce7e9@mail.gmail.com
Whole thread Raw
In response to Re: Application name patch - v2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Application name patch - v2
Re: Application name patch - v2
List pgsql-hackers
On Mon, Oct 19, 2009 at 10:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>> I thing, so change of original name should generate warning.
>
>> Well, if other people think that's necessary, it's certainly possible.
>
> I think Pavel's entire line of argument is utter nonsense.  He's setting
> up a straw man that has nothing to do with any actually likely use of
> the variable.

+1.  I can't even understand why we're still arguing about this.
Other than Pavel, everyone thinks this is a complete non-problem, and
Pavel's hypothesis basically boils down to "someone might use this
feature in a stupid and naive way".  Well, sure.  They might.  So
what?

> 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 don't have a strong feeling about this.  If limiting this to 7-bit
characters solves some nasty encoding problems or something, then
fine, but otherwise I think we can just escape what we emit into the
log and say that users who log this information should have a
sufficiently sophisticated log parser to cope with it.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Controlling changes in plpgsql variable resolution
Next
From: Tom Lane
Date:
Subject: Re: Writeable CTEs and side effects