Peter Eisentraut <peter_e@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
