From: | Pavel Stehule <pavel(dot)stehule(at)gmail(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:16:52 |
Message-ID: | 162867790907131216i48e3199cre827794a7b1de60d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
I did some similar (but Oracle like) in orafce - so it can help. I
thing, so this should be very useful, but result set isn't best
format. Usually you would to print to log and you have to iterate via
set. So maybe better format could be some structured text.
regards
Pavel Stehule
2009/7/13 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Hi,
>
> 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?
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-07-13 19:22:32 | Re: [RFC] obtaining the function call stack |
Previous Message | Sam Mason | 2009-07-13 19:15:27 | Re: New types for transparent encryption |