Re: CTE inlining

From: Thomas Kellerer <spam_eater(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: CTE inlining
Date: 2017-05-03 15:51:46
Message-ID: 1493826706018-5959509.post@n3.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I could tolerate telling people to use OFFSET 0 (and documenting it!)
> as a workaround if we can't get something more friendly in.

I agree with that.

> If we go with WITH INLINE then we're likely not solving anything, because
> most people will simply use WITH just like now, and will be subject to the
> fencing without realizing it.

I agree - the default behaviour should be change to match what everybody
expects. The current behaviour should be the exception.

> Yes, and we're missing the opportunity to confirm with what other
> systems do, and the spirit of the SQL language's declare what I want,
> not how to do it, model.

Essentially *all* other systems optimize CTEs the same way they optimize
derived tables. I think even MySQL does it like that in the upcoming 8.0
release.

I have never heard anyone saying that the Postgres implementation is an
advantage and that they would hate to see this disappear. I usually hear
"Why is Postgres doing that? Can't they change that?"

Maybe I have a limited view on this, but from where I stand, simply changing
it would help everybody I know and would not break anything. I don't even
think a replacement for the old behaviour would be necessary.

--
View this message in context: http://www.postgresql-archive.org/CTE-inlining-tp5958992p5959509.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-05-03 15:52:47 Re: password_encryption, default and 'plain' support
Previous Message Robert Haas 2017-05-03 15:47:04 Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)