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
>

Reply via email to