Dave Page wrote:
> Robert Haas wrote:
>
>> I also like PGAPPNAME better, for the same reasons as Tom.
>
> :-). Have to admit, I've mistyped it a few times too.
Well, it would seem we have consensus on that. :-)
I don't feel that the Java default issue reached the same level of
consensus, t
On Wed, Oct 21, 2009 at 4:29 PM, Robert Haas wrote:
> I also like PGAPPNAME better, for the same reasons as Tom.
:-). Have to admit, I've mistyped it a few times too.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start
--
Sent via p
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
Not sure I believe that argument. Among the set of existing libpq
On Wed, Oct 21, 2009 at 11:25 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Tom Lane wrote:
>>> FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
>
>> We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
>
> Not sure I believe that argument. Among the se
Andrew Dunstan writes:
> Tom Lane wrote:
>> FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
> We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
Not sure I believe that argument. Among the set of existing libpq
environment variables I see
PGHOSTADDR
Tom Lane wrote:
"Kevin Grittner" writes:
(or whatever name we choose for this in place of PGAPPNAME.)
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
Dave has been using in his examples. The latter is too frickin
long, and the double N is a typo threat (I already
"Kevin Grittner" writes:
> (or whatever name we choose for this in place of PGAPPNAME.)
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
Dave has been using in his examples. The latter is too frickin
long, and the double N is a typo threat (I already mistyped it in
composing thi
Tom Lane wrote:
> [ scratches head... ] I thought the JDBC spec already said exactly
> how one would set this. Why would we go to significant effort to
> make it behave contrary to spec?
We certainly should allow it to be set as specified in the spec. The
only question is whether it makes s
"Kevin Grittner" writes:
> Magnus Hagander wrote:
>> For java, it doesn't even go through libpq, so it wouldn't be set
>> for it. And I'd expect the JDBC driver to set it based on Something
>> Reasonable (TM) that it can get the information about. After all,
>> this thing was listed in the JDBC s
Magnus Hagander wrote:
> For java, it doesn't even go through libpq, so it wouldn't be set
> for it. And I'd expect the JDBC driver to set it based on Something
> Reasonable (TM) that it can get the information about. After all,
> this thing was listed in the JDBC spec somebody said...
I can't
daveg writes:
> I'd like a default, especially for psql, to help identify interactive
> sessions.
psql can certainly provide a default, and maybe even do something
actually useful like report the -f file it's running. The question here
is whether it is worth the trouble for libpq to try to repo
On Tue, Oct 20, 2009 at 12:16:42PM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > Also, how many platforms can't we do this on? If we have BSD and
> > Windows covered already. on linux, I believe you can easily read it
> > out of /proc/self/cmdline, no?
>
> Writing a pile of platform-specif
Magnus Hagander writes:
> 2009/10/20 Tom Lane :
>> "psql" or "java". The cases that are actually useful are the ones where
>> the application sets it. I don't think we should have a default at all
>> --- you don't set it, you don't get a name.
>
> For psql, yes.
What about having psql -f foo.sq
2009/10/20 Tom Lane :
> Magnus Hagander writes:
>> Also, how many platforms can't we do this on? If we have BSD and
>> Windows covered already. on linux, I believe you can easily read it
>> out of /proc/self/cmdline, no?
>
> Writing a pile of platform-specific code for this is simply insane from
>
Magnus Hagander writes:
> Also, how many platforms can't we do this on? If we have BSD and
> Windows covered already. on linux, I believe you can easily read it
> out of /proc/self/cmdline, no?
Writing a pile of platform-specific code for this is simply insane from
a support point of view. The f
Tom Lane wrote:
> if your software is written to depend on the appname being set a
> particular way
then you're not using for its intended purpose, I should think. Since
any client can set this to whatever they want, having the application
name as a default, rather than NULL (at least for cli
2009/10/20 Tom Lane :
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> It would be a seriously bad idea for this to behave one way on some
>>> platforms and differently on others.
>
>> Why would that be so bad? On platforms that support getting argv[0],
>> you'd get "mycoolapp" in the applicati
Heikki Linnakangas writes:
> Tom Lane wrote:
>> It would be a seriously bad idea for this to behave one way on some
>> platforms and differently on others.
> Why would that be so bad? On platforms that support getting argv[0],
> you'd get "mycoolapp" in the application name by default. On others,
Tom Lane wrote:
> Magnus Hagander writes:
>> 2009/10/20 Dave Page :
>>> Yeah, and there's a similar API on *BSD I believe, but nothing standard.
>
>> Right, but it might be worth investigating using the API that's
>> available on the platform, if one is. It's a fairly simple operation
>> after al
Magnus Hagander writes:
> 2009/10/20 Dave Page :
>> Yeah, and there's a similar API on *BSD I believe, but nothing standard.
> Right, but it might be worth investigating using the API that's
> available on the platform, if one is. It's a fairly simple operation
> after all, so it won't take huge
2009/10/20 Dave Page :
> On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander wrote:
>> 2009/10/19 Dave Page :
>>> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin wrote:
Would'nt this also make sense for PostgreSQL? That is, when no environment
is set, and no SET-command is issued
On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander wrote:
> 2009/10/19 Dave Page :
>> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin wrote:
>>>
>>> Would'nt this also make sense for PostgreSQL? That is, when no environment
>>> is set, and no SET-command is issued, that the application name be
2009/10/20 Bruce Momjian :
> Robert Haas 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 don't have a strong feeling about this. If limiting this to 7-bit
>> characters solves so
Robert Haas 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 don't have a strong feeling about this. If limiting this to 7-bit
> characters solves some nasty encoding problems or som
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin wrote:
>>
>> Would'nt this also make sense for PostgreSQL? That is, when no environment
>> is set, and no SET-command is issued, that the application name becomes the
>> default?
>
> That needs to be set by the applicati
2009/10/19 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> 2009/10/19 Stephen Frost :
>> > * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> >> Superuser permission could not be a problem. Simple security definer
>> >> function can do it.
>> >
>> > Then you've defeated the p
Robert Haas wrote:
> Tom Lane wrote:
>> I think Pavel's entire line of argument is utter nonsense.
> +1. I can't even understand why we're still arguing about this.
Agreed. One premise of the whole concept was "don't even think of
using it for security"[1]. That's not it's purpose; so an
David Fetter wrote:
> Could you point to a reference for this? It could help the rest of
us
> see what you're aiming for even better :)
Sybase Adaptive Server Enterprise (ASE)
clientapplname varchar(30) column in sysprocesses table:
http://infocenter.sybase.com/help/index.jsp?topic=/com.
On Mon, Oct 19, 2009 at 10:36 AM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule
>> 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 ent
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2009/10/19 Stephen Frost :
> > * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> >> Superuser permission could not be a problem. Simple security definer
> >> function can do it.
> >
> > Then you've defeated the point of making it superuser-only.
>
2009/10/19 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> Superuser permission could not be a problem. Simple security definer
>> function can do it.
>
> Then you've defeated the point of making it superuser-only.
no. Because when I write security definer function, then I ex
On Mon, Oct 19, 2009 at 3:49 PM, Tom Lane wrote:
> Stephen Frost 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 ju
Stephen Frost 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, sin
On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin wrote:
>
> Would'nt this also make sense for PostgreSQL? That is, when no environment
> is set, and no SET-command is issued, that the application name becomes the
> default?
That needs to be set by the application. As discussed previously,
the
> Sure. Here's a nice example from SQL Server as well as related doc links:
>
> http://blog.benhall.me.uk/2007/10/sql-connection-application-name.html
> http://msdn.microsoft.com/en-us/library/ms189770.aspx
>
> http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionst
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dave Page writes:
> > 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
David Fetter writes:
> On Mon, Oct 19, 2009 at 11:39:58AM +0100, Dave Page wrote:
>> Please bear in mind that this feature is based on similar features in
>> other DBMSs (and in fact, a feature in the JDBC spec)
> Could you point to a reference for this? It could help the rest of us
> see what y
On Mon, Oct 19, 2009 at 3:17 PM, David Fetter wrote:
> Could you point to a reference for this? It could help the rest of us
> see what you're aiming for even better :)
Sure. Here's a nice example from SQL Server as well as related doc links:
http://blog.benhall.me.uk/2007/10/sql-connection-ap
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2009/10/19 Heikki Linnakangas :
> > Or are you saying that it should not be possible for the client to
> > change the value after connecting? That limits the usefulness with
> > connection pools.
>
> What I know, connections from connection pool w
Dave Page writes:
> On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule
> 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 st
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Superuser permission could not be a problem. Simple security definer
> function can do it.
Then you've defeated the point of making it superuser-only.
I don't think that changing the app name deserves a warning, to be
perfectly honest. Notice sh
On Mon, Oct 19, 2009 at 11:39:58AM +0100, Dave Page wrote:
> Excuse me one moment whilst I pick myself up from the floor :-)
Heh!
> Can you imagine what a maintenance nightmare that would soon become?
Only vaguely, and that's enough.
> Please bear in mind that this feature is based on similar f
>
> -- monthly_report monthly_process.py:524
> select wev from foo;
>
> This feature would be very handy, but not if it requires special permission
> to use it.
Superuser permission could not be a problem. Simple security definer
function can do it.
Regards
Pavel
>
> -dg
>
>
> --
> David Goul
2009/10/19 Dimitri Fontaine :
> Andrew Dunstan writes:
>> Pavel Stehule wrote:
>>> Others GUC has not important role in logs. It's similar as possibility
>>> to change client IP address.
>>
>> That doesn't even remotely answer the question. How is such a thing a vector
>> for an SQL injection atta
Andrew Dunstan writes:
> Pavel Stehule wrote:
>> Others GUC has not important role in logs. It's similar as possibility
>> to change client IP address.
>
> That doesn't even remotely answer the question. How is such a thing a vector
> for an SQL injection attack, that does not apply to other GUCs?
On Mon, Oct 19, 2009 at 01:00:28PM +0100, Dave Page wrote:
> On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule
> wrote:
> > It is not practical. I'll log errors. Usually SQL injection generates
> > lot of errors. Loging all statements has not sense. What is difference
> > bad and good SQL statement
On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule wrote:
> It is not practical. I'll log errors. Usually SQL injection generates
> lot of errors. Loging all statements has not sense. What is difference
> bad and good SQL statement.? Maybe multistatements are good candidates
> for log as possible att
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 12:33 PM, Pavel Stehule
> wrote:
>> 2009/10/19 Dave Page :
>>> On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule
>>> wrote:
>>>
sure, you have to fix fulnerable application. But with some
unsophisticated using %a and using wrong tools, th
On Mon, Oct 19, 2009 at 12:33 PM, Pavel Stehule wrote:
> 2009/10/19 Dave Page :
>> On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule
>> wrote:
>>
>>> sure, you have to fix fulnerable application. But with some
>>> unsophisticated using %a and using wrong tools, the people can be
>>> blind and don'
2009/10/19 Pavel Stehule :
> 2009/10/19 Dave Page :
>> On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule
>> wrote:
>>
>>> sure, you have to fix fulnerable application. But with some
>>> unsophisticated using %a and using wrong tools, the people can be
>>> blind and don't register an SQL injection a
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule
> wrote:
>
>> sure, you have to fix fulnerable application. But with some
>> unsophisticated using %a and using wrong tools, the people can be
>> blind and don't register an SQL injection attack.
>
> If they're logging the s
On Mon, Oct 19, 2009 at 11:21 AM, Peter Eisentraut wrote:
>> A user can do that anyway if query logging is turned on, but anyway,
>> what would you suggest - accept a-zA-Z0-9 and a few other choice
>> characters only, or just reject a handful (and if so, what)?
>
> Well, either you make the thing
On Mon, 2009-10-19 at 08:47 +0100, Dave Page wrote:
> On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut wrote:
> > On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
> >> I think that covers all the suggestions discussed over the last couple
> >> of days, with the exception of the rejection of \n
Updated patch attached, fixing a silly thinko.
On Fri, Oct 16, 2009 at 12:58 PM, Dave Page wrote:
> I believe the attached patch is ready for review at the next
> commitfest. It does the following:
>
> - Adds a userset GUC called application_name.
> - Allows application_name to be reported in log
On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule wrote:
> sure, you have to fix fulnerable application. But with some
> unsophisticated using %a and using wrong tools, the people can be
> blind and don't register an SQL injection attack.
If they're logging the statements (which they presumably ar
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 10:22 AM, Pavel Stehule
> wrote:
>> 2009/10/19 Dave Page :
>>> On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule
>>> wrote:
>>>
There are some log parser's and analysers. So people use reduced log
often. The reductions rules should be bas
On Mon, Oct 19, 2009 at 10:22 AM, Pavel Stehule wrote:
> 2009/10/19 Dave Page :
>> On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule
>> wrote:
>>
>>> There are some log parser's and analysers. So people use reduced log
>>> often. The reductions rules should be based on application name. Why
>>> no
2009/10/19 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> 2009/10/19 Andrew Dunstan :
>>
>>>
>>> Pavel Stehule wrote:
>>>
2009/10/19 Dave Page :
>
> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
>
> wrote:
>
>
>>
>> I dislike write access to
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule
> wrote:
>
>> There are some log parser's and analysers. So people use reduced log
>> often. The reductions rules should be based on application name. Why
>> not? And when somebody modifies to appliacation name, then these l
Pavel Stehule wrote:
2009/10/19 Andrew Dunstan :
Pavel Stehule wrote:
2009/10/19 Dave Page :
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do it?
Tha
On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule wrote:
> There are some log parser's and analysers. So people use reduced log
> often. The reductions rules should be based on application name. Why
> not? And when somebody modifies to appliacation name, then these logs
> finish in '/dev/null.
So
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 9:36 AM, Pavel Stehule
> wrote:
>> Then we have to divide this value to two independent values like
>> application_name and application_state.
>
> How does that make any difference? That just means we have two values,
> at least one of which is sti
2009/10/19 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> 2009/10/19 Dave Page :
>>
>>>
>>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
>>> wrote:
>>>
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do it?
>>>
>>> That'll rend
On Mon, Oct 19, 2009 at 9:36 AM, Pavel Stehule wrote:
> Then we have to divide this value to two independent values like
> application_name and application_state.
How does that make any difference? That just means we have two values,
at least one of which is still userset, and means an additional
Pavel Stehule wrote:
2009/10/19 Dave Page :
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do it?
That'll render it pretty useless, as most applications wouldn't then
be able
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 9:23 AM, Pavel Stehule
> wrote:
>> 2009/10/19 Dave Page :
>>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
>>> wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do it?
>>>
>>> That'll
On Mon, Oct 19, 2009 at 9:23 AM, Pavel Stehule wrote:
> 2009/10/19 Dave Page :
>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
>> wrote:
>>> I dislike write access to app name guc for user too. It's not safe.
>>> Maybe only super user can do it?
>>
>> That'll render it pretty useless, as most
2009/10/19 Heikki Linnakangas :
> Pavel Stehule wrote:
>> 2009/10/19 Dave Page :
>>> On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut wrote:
So this would effectively allow any minimally authorized user to write
whatever they want into the log file whenever they want? Doesn't sound
>>>
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
> wrote:
>> I dislike write access to app name guc for user too. It's not safe.
>> Maybe only super user can do it?
>
> That'll render it pretty useless, as most applications wouldn't then
> be able to set/reset it when it ma
Pavel Stehule wrote:
> 2009/10/19 Dave Page :
>> On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut wrote:
>>> So this would effectively allow any minimally authorized user to write
>>> whatever they want into the log file whenever they want? Doesn't sound
>>> very safe to me.
>> A user can do tha
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule wrote:
> I dislike write access to app name guc for user too. It's not safe.
> Maybe only super user can do it?
That'll render it pretty useless, as most applications wouldn't then
be able to set/reset it when it makes sense to do so.
--
Dave Page
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut wrote:
>> On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
>>> I think that covers all the suggestions discussed over the last couple
>>> of days, with the exception of the rejection of \n and similar
>>> characters whic
On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut wrote:
> On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
>> I think that covers all the suggestions discussed over the last couple
>> of days, with the exception of the rejection of \n and similar
>> characters which I'm still not entirely conv
On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
> I think that covers all the suggestions discussed over the last couple
> of days, with the exception of the rejection of \n and similar
> characters which I'm still not entirely convinced is worth the effort.
> Any other opinions on that? Anythi
I believe the attached patch is ready for review at the next
commitfest. It does the following:
- Adds a userset GUC called application_name.
- Allows application_name to be reported in log_line_prefix using %a.
- Includes application_name in CSV logs.
- Displays application_name in the output of
75 matches
Mail list logo
