From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: eval_const_expresisions and ScalarArrayOpExpr |
Date: | 2017-05-11 16:20:55 |
Message-ID: | 4b14a9a5-01c2-4042-3ec9-cf27149302a5@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/11/2017 06:21 PM, Tom Lane wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-11 16:41:02 | Safer and faster get_attstatsslot() |
Previous Message | Remi Colinet | 2017-05-11 16:15:56 | Re: [PATCH v2] Progress command to monitor progression of long running SQL queries |