Re: Problem in ExecEvalExpr function
От | Martijn van Oosterhout |
---|---|
Тема | Re: Problem in ExecEvalExpr function |
Дата | |
Msg-id | 20051018093526.GB8155@svana.org обсуждение исходный текст |
Ответ на | Problem in ExecEvalExpr function (sandeep satpal <sandeep@it.iitb.ac.in>) |
Ответы |
Re: Problem in ExecEvalExpr function
|
Список | pgsql-hackers |
On Tue, Oct 18, 2005 at 02:38:39PM +0530, sandeep satpal wrote: > > Hi, > > I have some doubts related to ExecEvalExpr functions which is used to > executing the expression. Since they are operators, they go through ExecEvalOper. However, after the first call they go through ExecMakeFunctionResult. The operator has an oid which is used to find the function and it is eventually called using FunctionCallInvoke. Note, ExecEvalExpr is a macro, so you can't break on it. > Here we are finding the subexpression recursively. > But I am not able to find it out that where exactly the comparison taking > place. > For eg. > relation A > id name age > relation B > name age status > > if query is > select id , name , age , status from A , B where A.name = B.name and A.age > = B.age. Note that if the operator appears in the OPERATOR CLASS and the optimizer has determined that it can use an index, it won't go through this code at all, instead using the compare function in _bt_compare. > Then parser find this "and" condition and divide this into two expression. > But I am not getting in which function exactly these comparison between > tupleslot taking place. FunctionCallInvoke will be calling the function for operator =. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
В списке pgsql-hackers по дате отправления: