|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|Subject:||Re: eval_const_expresisions and ScalarArrayOpExpr|
|Views:||Raw Message | Whole Thread | Download mbox|
Heikki Linnakangas <hlinnaka(at)iki(dot)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. 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).
> 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.
regards, tom lane
|Next Message||Remi Colinet||2017-05-11 15:24:16||Re: [PATCH v2] Progress command to monitor progression of long running SQL queries|
|Previous Message||Daniel Verite||2017-05-11 15:16:06||Re: export import bytea from psql|