From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] obtaining the function call stack |
Date: | 2009-07-13 19:41:28 |
Message-ID: | 4A5B8DE8.4070406@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera wrote:
> This is a preliminary request for comments on obtaining a function call
> stack. I've been trying to dodge the issue by exporting elog.c internal
> state (errcontext), but that turns out to be unfeasible and it's such a
> horrid kludge anyway.
>
> So, the idea is to have a stack maintained by the function manager; each
> called function enters an element in it containing the interesting
> information about the function. We'd have another function that would
> return this stack as a result set. (With this arrangement, the topmost
> element would always appear to be this "peek" function.)
>
> I haven't looked at the code to see how this would actually be
> implemented, so I don't have more details to offer. Does anybody have
> opinions on the matter?
FWIW, pldebugger obtains a function call stack by peeking into the error
context stack. It only includes PLpgSQL functions, and it's ugly and
hacky. Something cleaner would simplify pldebugger, although it's always
going to be hacky since it needs to understand quite a lot about PLpgSQL
internal structures to display variables and stuff.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-07-13 19:45:47 | Re: Alpha release process |
Previous Message | Pavel Stehule | 2009-07-13 19:36:13 | Re: [RFC] obtaining the function call stack |