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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
