Douglas Doole <dougdo...@gmail.com> writes: >> TBH I dislike the fact that >> you did the subquery case randomly differently from the existing cases; >> it should just have been added as an additional recursive case. Since >> this is done only once at query startup, worrying about hypothetical >> micro-performance issues seems rather misguided.
> Habit mostly - why write code with potential performance problems when the > alternative is just as easy to read? I disagree that having adjacent code doing the same thing in two different ways is "easy to read"; what it is is confusing. More globally, since we're dealing with community code that will be read and hacked on by many people, I think we need to prioritize simplicity, readability, and extensibility over micro-efficiency. I'm willing to compromise those goals for efficiency where a clear need has been demonstrated, but no such need has been shown here, nor do I think it's likely that one can be shown. I'd have been okay with changing the entire function if it could still be doing all cases the same way. But the exception for merge-append (and probably soon other cases) means you still end up with a readability problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers