On Sun, May 30, 2010 at 6:58 PM, Andrew Dunstan <and...@dunslane.net> wrote:
> Tim Bunce wrote:
>> p.s. It also turned to be insufficiently useful for NYTProf since it
>> doesn't also update some internals to record the 'filename' and line
>> number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
>> that by wrapping mkfuncsrc() to edit the generated perl code to include
>> a subname in the usual "sub $name { ... }" style. I may offer a patch
>> for 9.1 to to make it work that way.
>
> I put this aside to think about it.
>
> If the "feature" is not any use should we rip it out? We pretty much
> included it because you said it was what you needed for the profiler.
>
> I'm seriously nervous about adding function names - making functions
> directly callable like that could be a major footgun recipe, since now we
> are free to hide some stuff in the calling mechanism, and can (and have in
> the past) changed that to suit our needs, e.g. when we added trigger support
> via a hidden function argument. That has been safe precisely because nobody
> has had a handle on the subroutine which would enable it to be called
> directly from perl code. There have been suggestions in the past of using
> this for other features, so we should not assume that the calling mechanism
> is fixed in stone.
>
> Perhaps we could decorate the subs with attributes, or is that not doable
> for anonymous subs?This is still on our open items list - should we do anything about it? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
