Re: Mapping MERGE onto CTEs (Re: MERGE SQL Statement for PG11)

Craig Ringer <craig@2ndquadrant.com>

From: Craig Ringer <craig@2ndquadrant.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Nico Williams <nico@cryptonector.com>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-11-02T08:06:50Z
Lists: pgsql-hackers
On 2 November 2017 at 01:14, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Nico Williams wrote:
>
>> As an aside, I'd like to be able to control which CTEs are view-like and
>> which are table-like.  In SQLite3, for example, they are all view-like,
>> and the optimizer will act accordingly, whereas in PG they are all
>> table-like, and thus optimizer barriers.
>
> There was a short and easy to grasp (OK, maybe not) discussion on the
> topic of CTEs acting differently.  I think the consensus is that for
> CTEs that are read-only and do not use functions that aren't immutable,
> they may be considered for inlining.
> https://www.postgresql.org/message-id/5351711493487900@web53g.yandex.ru

Yep. All theoretical though, I don't think anyone (myself included)
stumped up a patch.


-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Commits

  1. Add support for MERGE SQL command

  2. Add API of sorts for transition table handling in trigger.c

  3. Revert MERGE patch

  4. Fix several bugs related to ON CONFLICT's EXCLUDED pseudo relation.