"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> I'm a bit puzzled myself why this affects SELECT FOR UPDATE/SHARE but not >> straight UPDATES and DELETES. > > In straight UPDATE/DELETE we have enough structure in the query to know > how to associate each tuple returned to the executor top level with > exactly one tuple in exactly one target table (which is where to apply > the tuple lock operation). We don't have that much structure in general > SELECT --- for example, what to do with null-filled rows in a LEFT JOIN, > or cases where one row gives rise to more than one joined row, or > aggregation or UNION? Some of these cases can probably be rejected as > unsupportable, but it'll still take a lot of work.
This seems like the same kind of work that would be required to support queries like UPDATE (SELECT a, t1.b AS src, t2.b AS dest FROM t1 join t2 USING (a) ) SET dest = src; We currently support such plans using the FROM clause but handling arbitrary queries (where they make sense) would be far more flexible. It would also let us support updateable views in a much more flexible way than trying to reverse engineer the view to generate rules. Instead the rules would be straightforward substitutions just like the select rules: UPDATE view SET ... would just become: UPDATE (view-definition) SET ... And it would be up to the executor to determine whether which table the target columns came from and whether they're updateable or the query should throw an error. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate