Peter Eisentraut <pete...@gmx.net> writes: > On tis, 2009-09-15 at 11:32 -0400, Tom Lane wrote: >> FWIW, I don't particularly agree with that --- there is no reason to >> suppose that all PLs will want to do this exactly the same way.
> I'd imagine that we simply set the context to "$language function > $name", probably in fmgr_info_other_lang(). If a language wants more > than that, it can set another level of context. So if we want to emit something like "$language function $name line $lineno", that now has to be two separate lines of context? There'd be no clean way for the PL to suppress the one it doesn't really need. > Of course this way we > would not save much code in, say, PL/Perl, but all the other PLs that > are currently not using this stuff at all would get it for free. It would be very far from being "for free", because there's no inexpensive way for a general-purpose hook to get hold of either $language or $name without knowing anything about the internals of the PL. It would have to fetch the relevant pg_language and pg_proc rows, the former being unnecessary for the PL itself, and the latter being almost certainly redundant with what the PL is doing. You could eliminate the performance objection perhaps by fetching the rows only if the context hook is actually called, but then you have added failure modes that weren't there before (if the fetch fails for some reason). Also, there is noplace to establish the hook anyway (without adding another layer of call overhead). fmgr_info cannot do it, because it's not in the actual runtime call chain. Between the expense, the low return, and the high probability of not being exactly what's wanted, I don't think this seems like a good design choice. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers