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

Re: FOR UPDATE versus WITH --- change 8.4 too?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FOR UPDATE versus WITH --- change 8.4 too?
Date: 2009-10-27 17:02:53
Message-ID: 603c8f070910271002u3fe61f73s206c886e41469e11@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Oct 27, 2009 at 10:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In yesterday's discussions about FOR UPDATE there was some mention of
> making it not propagate into WITH subqueries:
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg01540.php
> That is, given
>  WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE
> should foo be locked FOR UPDATE or not?  The current behavior is that
> the code attempts to propagate FOR UPDATE into the WITH, and fails
> (the parser rejects it in some cases, and the planner in others ---
> AFAICT there is no case where it actually works).  This is pretty
> useless, and it's also at odds with the philosophy we adopted that WITH
> queries execute independently of the primary query.  So I think there
> was consensus to change it to have FOR UPDATE ignore WITH references.
>
> What I'm wondering at the moment is if there's any objection to
> back-patching the change into 8.4.  Given the lack of any way to have a
> working query depend on this behavior, it doesn't seem that there could
> be a problem, but can anyone think of an objection I missed?

If it doesn't have any effect anyway, what's the virtue of back-patching it?

It seems like we might want to throw an error rather than silently
ignoring it, but that obviously wouldn't be back-patchable.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-10-27 17:06:30
Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Previous:From: Josh BerkusDate: 2009-10-27 17:01:51
Subject: Re: Should we warn users about SETs which have no effect?

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