Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr |
Дата | |
Msg-id | 4b14a9a5-01c2-4042-3ec9-cf27149302a5@iki.fi обсуждение исходный текст |
Ответ на | Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr
Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr |
Список | pgsql-hackers |
On 05/11/2017 06:21 PM, Tom Lane wrote: > Heikki Linnakangas <hlinnaka@iki.fi> writes: >> Eval_const_expressions() doesn't know about ScalarArrayOpExpr. >> ... >> That seems like an oversight. I guess that scenario doesn't happen very >> often in practice, but there's no reason not to do it when it does. >> Patch attached. > > Yeah, I think it's a lack-of-round-tuits situation. Your patch reminds > me of a more ambitious attempt I made awhile back to reduce the amount > of duplicative boilerplate in eval_const_expressions. I think I wrote > it during last year's beta period, stashed it because I didn't feel like > arguing for applying it right then, and then forgot about it. Hmph, now we're almost in beta period again. :-(. > Blowing the dust off, it's attached. It fixes ArrayRef and RowExpr as > well as ScalarArrayOpExpr, with a net growth of only 20 lines > (largely comments). Nice! >> On a side-note, I find it a bit awkward that ScalarArrayOpExpr uses a >> 2-element List to hold the scalar and array arguments. Wouldn't it be >> much more straightforward to have explicit "Expr *scalararg" and "Expr >> *arrayarg" fields? > > I think it's modeled on OpExpr, which also uses a list though you could > argue for separate leftarg and rightarg fields instead. Yeah, I think that would be better for OpExpr, too. (For an unary operator, rightarg would be unused.) - Heikki
В списке pgsql-hackers по дате отправления: