Status report on writeable CTEs

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Status report on writeable CTEs
Дата
Msg-id 4C3B59E7.7090002@cs.helsinki.fi
обсуждение исходный текст
Ответы Re: Status report on writeable CTEs  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Re: Status report on writeable CTEs  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Status report on writeable CTEs  (Hitoshi Harada <umi.tanuki@gmail.com>)
Список pgsql-hackers
Hi,


I've been working on writeable CTEs during the last couple of months,
but right now it looks like I'm going to miss the first commit fest for
9.1.  I was trying to make it work by expanding all wCTEs to their own
Queries during the rewrite stage (a very crude patch trying to do that
for regular CTEs attached), but I don't think that it's a good way of
approaching the problem.  Consider:

WITH t  AS (SELECT 1),
      t2 AS (SELECT * FROM t2)
VALUES (true);

The first big problem I hit is was that when the query for t2 is planned
separately, it doesn't have the CTE information.  But even if it had
that information (we could easily copy it during the rewrite stage), all
RTEs referencing CTEs that were expanded would have the wrong levelsup
(this is where the patch fails at regression tests).  One could probably
come up with ways of fixing even that, but I don't think that's the
right direction to be heading.

So what I'm now thinking of is making the planner plan that as a single
Query, and make the planner expand it into multiple PlannedStmts if
necessary.  This would break the existing planner hooks, but I don't
think that's a huge problem.  Does anyone see any obvious flaws in this?

Any feedback is welcome.  I'd also be happy to get some help on this
project.


Regards,
Marko Tiikkaja

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: patch (for 9.1) string functions
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: Status report on writeable CTEs