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
