From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: eval_const_expresisions and ScalarArrayOpExpr |
Date: | 2017-05-11 15:21:00 |
Message-ID: | 23186.1494516060@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
better-eval-const-expressions-1.patch | text/x-diff | 14.5 KB |
From | Date | Subject | |
---|---|---|---|
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 |