On Sat, 13 Jun 2020 at 16:07, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > David Rowley <dgrowleyml@xxxxxxxxx> writes: > > I wondered if it would be more simple to add some smarts to look a bit > > deeper into case statements for selectivity estimation purposes. An > > OpExpr like: > > CASE c.contype WHEN 'c' THEN 'CHECK' WHEN 'f' THEN 'FOREIGN KEY' WHEN > > 'p' THEN 'PRIMARY KEY' WHEN 'u' THEN 'UNIQUE' END = 'CHECK'; > > Hm. Maybe we could reasonably assume that the equality operators used > for such constructs are error-and-side-effect-free, thus dodging the > semantic problem I mentioned in the other thread? I'm only really talking about selectivity estimation only for now. I'm not really sure why we'd need to ensure that the equality operator is error and side effect free. We'd surely only be executing the case statement's operator's oprrest function? We'd need to ensure we don't invoke any casts that could error out. David
