Skip site navigation (1) Skip section navigation (2)

Re: Writeable CTEs patch

From: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Writeable CTEs patch
Date: 2010-02-09 20:13:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 2010-02-08 18:42 +0200, Robert Haas wrote:
> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
> <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> wrote:
>> Here's an updated patch.  Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
> - I'm not sure that canSetTag is the right name for the additional
> argument to ExecInsert/ExecUpdate/ExecDelete.  OTOH, I'm not sure it's
> the wrong name either.  But should we use something like
> isTopLevelQuery?

I'm going to have to take back my previous statement; this doesn't make
a lot of sense in the case of DO ALSO rules (or multiple statements in a
DO INSTEAD RULE).  Those will have canSetTag=false, but they will be at
the top level.

> - It appears that we pull out all of the DML statements first and run
> them in order, but I'm not sure that's the right thing to do.
> Consider:
> WITH x AS (INSERT ...), y AS (SELECT ...), z AS (INSERT ...) SELECT ...
> I would assume we would do x, CCI, do y, do z, CCI, do main query, but
> I don't think that's what this implements.  The user might be
> surprised to find out that y sees the effects of z.

I went ahead and implemented this, but there seems to be one small
problem: RECURSIVE.  If there is a recursive query between those, it
might loop forever even if the top-level SELECT only wanted to see a few
rows from it.  The docs already discourage writing recursive ctes like
that, but still this is a small caveat.

> - It seems like the gram.y changes for common_table_expr might benefit
> from some factoring; that is, create a production (or find a suitable
> existing one) for "statements of the sort that can appear within
> CTEs", and then use that in common_table_expr.  Or maybe this doesn't
> work; I haven't tried it.

This seems to work.  I used PreparableStmt, but I'm not sure how good
idea that really is.  Maybe I should create a new one?

Marko Tiikkaja

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-09 20:20:40
Subject: Re: CreateFakeRelcacheEntry versus Hot Standby
Previous:From: Heikki LinnakangasDate: 2010-02-09 20:03:41
Subject: Re: CreateFakeRelcacheEntry versus Hot Standby

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group