On Mon, Jul 13, 2015 at 1:56 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> On 7/13/15 3:39 PM, dinesh kumar wrote: > >> I don't really see the point of what you're describing here. Just do >> something like RAISE WARNING which should normally be high enough to >> make it into the logs. Or use a pl language that will let you write >> your own logfile on the server (ie: plperlu). >> >> True. Using plperlu, shall we bypass our log_* settings. If it's true, i >> wasn't sure about it. >> > > plperlu can do anything the server can do. Including fun things like > appending to any file the server can write to or executing things like `rm > -rf pg_xlog`. Thanks Much Jim. > > > I didn't mean that, we need to have this feature, since we have >> it on >> other RDBMS. I don't see a reason, why don't we have this in our >> PG too. >> >> I see the similar item in our development list >> < >> http://www.postgresql.org/message-id/53a8e96e.9060...@2ndquadrant.com>. >> >> >> That's not at all what that item is talking about. It's talking >> about exposing ereport as a SQL function, without altering the rest >> of our logging behavior. >> >> >> Ah. It's' my bad interpretation. Let me work on it, and will send a new >> patch as a wrapper sql function for ereport. >> > > You might want to present a plan for that; it's not as trivial as it > sounds due to how ereport works. In particular, I'd want to see (at > minimum) the same functionality that plpgsql's RAISE command now provides > (errdetail, errhint, etc). > > Sure. Let me prepare a prototype for it, and will share with you before implementing. Best Regards, Dinesh manojadinesh.blogspot.com > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Data in Trouble? Get it in Treble! http://BlueTreble.com >
