Robert Haas <robertmhaas@gmail.com> writes:
> Like Pavel, and I think implicitly Dagfinn and Andres, I'm not sure I
> believe this. Pavel's example is a good one. The leakproof exception
> helps, but it doesn't cover everything. Users I've encountered throw
> things like date_trunc() and lpad() into SQL code and expect them to
> behave (from a performance point of view) like constants, but they
> also expect 1/0 not to get evaluated too early when e.g. CASE is used.
> It's difficult to meet both sets of expectations at the same time and
> we're probably never going to have a perfect solution, but I think
> you're minimizing the concern too much here.
I've quoted this point before, but ... we can make queries arbitrarily
fast, if we don't have to give the right answer. I think we've seen
enough complaints on this topic now to make it clear that what we're
doing today with CASE is the wrong answer.
The performance argument can be made to cut both ways, too. If somebody's
got a very expensive function in a CASE arm that they don't expect to
reach, having it be evaluated anyway because it's got constant inputs
isn't going to make them happy.
The real bottom line is: if you don't want to do this, how else do
you want to fix the problem? I'm no longer willing to deny that
there is a problem.
> I don't think I believe this either. I don't think an average user is
> going to expect <expression> to behave differently from (SELECT
> <expression>).
Agreed, that's poorly (or not at all?) documented. But it's been
true all along, and this patch isn't changing that behavior at all.
I'm not sure if we should do anything more than improve the docs,
but in any case it seems independent of the CASE issue.
> The current behavior isn't great, but at least it handles these
> cases consistently.
Really?
regards, tom lane