Re: eval_const_expresisions and ScalarArrayOpExpr

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
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

In response to

Responses

Browse pgsql-hackers by date

  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