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`.
> 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.9060507@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).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
