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.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).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
