On 2013-01-25 21:07:51 +0100, Andres Freund wrote: > On 2013-01-25 14:51:39 -0500, Tom Lane wrote: > > Andres Freund <and...@2ndquadrant.com> writes: > > > Its slightly more complex than just making it one hash table with an > > > extended key. When validating a trigger function we don't have a > > > relation to do the cache lookup. I chose to handle that case by not > > > doing a cache lookup at all in that case which imo is a sensible > > > choice. > > > > Seems fair. However ... why is it safe for PLy_procedure_create to be > > using the same name for multiple instances of a trigger function? > > Should we not be including the rel OID when building the procName > > string? > > I don't think its a problem, given the way python works I am pretty sure > it will result in independent functions. > > Each PLy_procedure_compile will run the source code in a copy of > PLy_interp_globals, therefore the independent comilitions shouldn't > affect each other. > > I am not sure why it builds the call to the function via eval'ing a > "$funcname()" instead of using the result of PyRun_String which will > return a reference to the function, but thats an independent issue. > > Now I think an argument can be made that it would be nicer for debugging > purposes to have clearly distinguishable function names, but I > personally never needed it and it probably wouldn't be something to > backpatch. People might rely on those function names.
Just for fun I tried how easy it is to have some fun with the function name. Guess what happens when the attached sql file is executed ;) quite possibly doesn't work if copied from here but for quicker viewing: CREATE OR REPLACE FUNCTION "foo(): pass import os os._exit(1) def "() RETURNS void LANGUAGE plpythonu AS $$pass$$; Yep: LOG: server process (PID 29317) exited with exit code 1 DETAIL: Failed process was running: CREATE OR REPLACE FUNCTION "foo(): pass import os os._exit(1) def "() RETURNS void LANGUAGE plpythonu AS $$pass$$; LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. Anyway, back to more sensible things ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs