From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Call stacks and RAISE INFO |
Date: | 2011-10-15 21:02:23 |
Message-ID: | 4E99F4DF.8080708@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> No, I don't think so. The use-case for this sort of thing seems to me
> to be messages that are directed to the user or DBA, and don't want to
> be decorated with a lot of information about where they came from.
> That determination is usually pretty clear when you write the code.
For my case, I agree with Tom. For example, in my recent debugging
session, I was debugging a recursive function ... one which calls
itself, up to 6 levels deep. For that function, I want to turn context
off because there's so much it becomes unreadable, and instead I put a
nesting counter in the INFO.
I don't want to turn of context for other functions universally -- even
in the same ETL session -- because I want to know what called them,
since some of them can be called on multiple paths.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2011-10-15 21:16:05 | Re: index-only scans |
Previous Message | Tom Lane | 2011-10-15 18:58:45 | Pushing ScalarArrayOpExpr support into the btree index AM |