From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sandro Santilli <strk(at)keybit(dot)net>, pgsql-bugs(at)postgresql(dot)org, peter_e(at)gmx(dot)net |
Subject: | Re: cache lookup failed from empty plpythonu function |
Date: | 2013-01-25 20:07:51 |
Message-ID: | 20130125200751.GA27601@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-01-25 20:15:32 | Re: Re: BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262" |
Previous Message | Alvaro Herrera | 2013-01-25 19:57:16 | Re: Re: BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262" |