Re: cache lookup failed from empty plpythonu function
От | Andres Freund |
---|---|
Тема | Re: cache lookup failed from empty plpythonu function |
Дата | |
Msg-id | 20130125200751.GA27601@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: cache lookup failed from empty plpythonu function (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: cache lookup failed from empty plpythonu function
|
Список | pgsql-bugs |
On 2013-01-25 14:51:39 -0500, Tom Lane wrote: > Andres Freund <andres@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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-bugs по дате отправления: