On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning <d...@kavod.com> wrote: > Another good reason to reject it might be because the only way to disable > the CTE fence is to disable it by default. If that were the case, then I > would imagine that it would break backwards compatibility, especially in the > case of writable CTEs that currently depend on the fence for their current > functionality.
Yeah: I constantly rely on CTE fencing and it's a frequently suggested performance trick on the lists. LATERAL is coming out soon and this will remove one of the largest reasons to fence but there are of course others. Also, a GUC setting is almost certainly the wrong approach. I'm wondering if there are any technical/standards constraints that are behind the fencing behavior. If there aren't any, maybe an opt-in keyword might do the trick -- WITH UNBOXED foo AS (..)? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
