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:
> 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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-10-27 17:06:30|
|Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order |
|Previous:||From: Josh Berkus||Date: 2009-10-27 17:01:51|
|Subject: Re: Should we warn users about SETs which have no effect?|