Re: Doc Patch: Subquery section to say that subqueries can't modify data - Mailing list pgsql-hackers

From David Johnston
Subject Re: Doc Patch: Subquery section to say that subqueries can't modify data
Date
Msg-id 1375827328364-5766580.post@n5.nabble.com
Whole thread Raw
In response to Doc Patch: Subquery section to say that subqueries can't modify data  ("Karl O. Pinc" <kop@meme.com>)
Responses Re: Re: Doc Patch: Subquery section to say that subqueries can't modify data  ("Karl O. Pinc" <kop@meme.com>)
List pgsql-hackers
Instead of simply expanding the section on sub-queries, which may still be
worthwhile, it seems that we have effectively introduced a new "kind" of
query - namely one that mixes both query DDL and update DDL into a kind of
hybrid query.  An entire section describing the means to implement these
queries and the limitations thereof would seem advisable as the current
material is spread throughout the documentation.

Some areas to address would:

Select queries that cause/utilize:

function-based modifications
CTE-based modifications
FDW/dblink-based modifications

I guess the main question is if someone were to put this together would it
likely be included in the "queries" section of the documentation.  Also, are
there any other thoughts to add; and is something like this documented in a
ToDo somewhere already?

The proposed patch; while warranting a technical review (namely that the
presence of functions in a sub-select can cause the sub-query to update the
database), seems to add one more place to go find this information without
adding a central index or summary that someone learning the system could
directly comprehend/learn as opposed to it being some allowed/disallowed
side-effect to something else.

David J.





--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Doc-Patch-Subquery-section-to-say-that-subqueries-can-t-modify-data-tp5766574p5766580.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Review: UNNEST (and other functions) WITH ORDINALITY
Next
From: Alvaro Herrera
Date:
Subject: refactor heap_deform_tuple guts