Re: [RFC] obtaining the function call stack

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

In response to

Browse pgsql-hackers by date

  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