Tom Lane wrote:
>The subquery isn't pulled up because it doesn't pass the
>has_nullable_targetlist test in src/backend/optimizer/plan/planner.c.
>If we did flatten it, then references to calc_col wouldn't correctly
>go to NULL when the LEFT JOIN should make them do so --- they'd be
>22 all the time.
>
>As the notes in that routine say, it could be made smarter: strict
>functions of nullable variables could be allowed. So if your real
>concern is not '22' but something like 'othercol + 22' then this is
>fixable.
>
> regards, tom lane
>
>
>
Tom,
actually my views do use calculated columns (mostly concated strings,
e.g. full name from title/1st/last name). As the example shows even
columns that are never used will be taken into account when checking
has_nullable_targetlist. Unfortunately I have a lot of views containing
views which containing.... delivering a lot more columns than needed.
But they are checked anyway...
I'd expect the parser to look at the join construction only to find out
about available data. Why should the selected (and even unselected)
columns be evaluated if the join delivers no result? Maybe this can be
achieved by checking only JOIN ON/WHERE columns with
has_nullable_targetlist?
Regards,
Andreas
