Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
От | Bernard Frankpitt |
---|---|
Тема | Re: [HACKERS] Early evaluation of constant expresions (with PATCH) |
Дата | |
Msg-id | 37E8F708.B55D6A21@pop.dn.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Early evaluation of constant expresions (with PATCH) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
|
Список | pgsql-hackers |
Tom Lane wrote: > > .... (Actually, now > that I look at it, it looks like the functions rather than the > operators are missing the necessary preinitialization. Perhaps at > the place where you chose to put this in, setFcache has already > been done?) > The functions work because the funcid field in the Func node is already filled in, and the EvalQual code uses this field to generate the Fcache. In the case of Oper node there are two fields, one for the pg_operator Oid, and one for the pg_proc Oid. The pg_operator oid is already filled in, but the pg_proc oid isn't. The EvalQual code wants the pg_proc oid, so I provide it in the patch before I do the evaluation. > > There are additional smarts that could/should be put in, though. .... > > { Many good suggestions here } > > .... without adding a flag to pg_proc that tells us if it is OK. > All points well taken. I don't have time to do this thoroughly right now, but I will get back to it. My original ( needed-for-project-at-hand ) motivation for this was to get index scans to work with expressions that evaluate to constants. I can see that I am about to learn quite a bit more about parsing and planning. > > I puzzled over case of now() for a while but I don't think that it > > raises a problem. > > No, you can't just define the problem away by saying that whatever > behavior is convenient to implement is acceptable. Oh darn! -- I've spent too many years studying mathematics > and user-defined functions could be a problem. SQL functions probably > shouldn't be folded either (not quite sure of that). > > Bruce points out in another reply that the proiscachable field of > pg_proc is intended for exactly this purpose. Perhaps adding another option to create function is in order here. I know how to do that already. Seriously, there are some interesting semantic issues here, especially if the database were being used as the basis for a large dynamic stochastic model. Bernie
В списке pgsql-hackers по дате отправления: