Re: Possible bug in CASE evaluation

On Fri, Jun 21, 2013 at 09:20:21AM +0000, Albe Laurenz wrote:
> Andres Freund wrote:
> > Yes, I think it's pretty clearly a bug - Tom doesn't seem think so
> > though. If we can agree it is, the fix outlined over on -bugs seems to
> > be easily enough implemented...

If you refer to this:

On Tue, Jun 18, 2013 at 03:31:32PM +0200, Andres Freund wrote:
> So it seems we need to stop processing after finding a single WHEN
> that's not const? Does anybody have a better idea?

eval_const_expressions() is not just an optimization: it performs mandatory
transformations such as the conversion of named-argument function calls to
positional function calls. Even if you could skip it, queries with expensive
constant expressions would notice the performance loss. The situations helped
by a change like this are too marginal to accept that cost.

Would it work to run eval_const_expressions() lazily on THEN clauses? The
plan-time eval_const_expressions() would not descend to them. The first
ExecEvalCase() to use a given THEN clause would run eval_const_expressions()
before proceeding.

> I think that it is surprising behaviour.

That's about how I characterize it, too.

I question whether real applications care. It's important to have CASE usable
for avoiding data-dependent errors, but what's the use of including in your
query an expression that can do nothing but throw an error? Does anyone have
a real-world example? Perhaps some generated-query scenario.

That being said, if we discover a simple-enough fix that performs well, we may
as well incorporate it.

> If fixing the behaviour is undesirable, at least the documentation
> should be fixed.

A brief documentation mention sounds fine. Perhaps add a paragraph on
constant folding in general and reference that from the CASE page.

Thanks,
nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com