Re: ExecEvalExpr: unknown expression type 108
От | SZŰCS Gábor |
---|---|
Тема | Re: ExecEvalExpr: unknown expression type 108 |
Дата | |
Msg-id | 008b01c2a129$7d9cbbf0$0a03a8c0@fejleszt2 обсуждение исходный текст |
Ответ на | ExecEvalExpr: unknown expression type 108 ("SZŰCS Gábor" <surrano@mailbox.hu>) |
Список | pgsql-general |
Thanks Krisztian, I checked google and most of the pgsql archive messages it pointed to, but I found that this message is commonly related to subselects in table constraints. If I didn't misunderstand it, Tom once titled this as "probably solved in 6.5" or such, back in 1999. However, my problem is different, and even if it's not vital now, I'd like to get some suggestions where to search if the problem persists. I use 7.2.1 and met the problem BUT ONCE, after changing a field definition in a view from a function call to the explicit content of the function, like this: -- t and x are business files, -- with items referring to t in t_item -- and their N:M relations with x and x_item (not important now) in t_x. -- I want to select the latest x.id from the relations table: -- -- myfunc(t.id, t_item.no) AS x, -- this was the original (SELECT x FROM t_x WHERE t_x.t = t.id AND t_x.t_item = t_item.no ORDER BY tstamp DESC LIMIT 1 ) AS x, The error message occured after I recreated the view (and its rule), but when I tried to reproduce it to send a usable mail, it evilly refused to fail and works correctly ever since ;) I fear for the worst, that the problem comes to life again when it goes from test to live use. Well, even if it comes to life, I can get back to calling that function; the problem is, that if I wish to JOIN with table x using this field of the view, the planner makes a seq scan on table x, unlike when I write the function body in the view definition. Since one produces 17sec and the other 0.11sec as total time for the same query, I think the planner doesn't deliberately choose seq scan; it can't choose index scan. So, I helped it to see what I want in depth, and that caused the error -- I repeat, it caused the error but once. G. -- while (!asleep()) sheep++; ---------------------------- cut here ------------------------------ ----- Original Message ----- From: "Hegyvari Krisztian" <Hegyvari.Krisztian@ardents.hu> Sent: Tuesday, December 10, 2002 5:12 PM Dear Gabor, I am far from being a guru, so I typed "ExecEvalExpr: unknown expression type 108" into google and it came up with some seemingly useful hits.
В списке pgsql-general по дате отправления: