From: | "Karl O(dot) Pinc" <kop(at)meme(dot)com> |
---|---|
To: | David Johnston <polobo(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: Doc Patch: Subquery section to say that subqueries can't modify data |
Date: | 2013-08-06 23:50:23 |
Message-ID: | 1375833023.16544.2@slate |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Good points.
On 08/06/2013 05:15:28 PM, David Johnston wrote:
> 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.
The proposed patch is an attempt to provide a base upon
which to build such a section.
>
> Some areas to address would:
>
> Select queries that cause/utilize:
>
> function-based modifications
> CTE-based modifications
> FDW/dblink-based modifications
While it'd be nice to have a full set of examples and an
exhaustive list of what constitutes modification and
what does not it should be enough to state where, in
this sort of hybrid query, modification is allowed
and where not. Of course more detail is needed if
the different kinds of modification above are restricted
in different ways.
>
> 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.
If this section is not to be part of the Query chapter then it
surely also does not belong in the Data Manipulation chapter
(or the Data Definition chapter),
if for no other reason than the information presented in the
Query chapter is necessary to understand the subject.
To me that means it needs it's own chapter, probably immediately
following the Query chapter. I can't think what to call
such a chapter.
> 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.
I'm less worried about data modifying functions than I am
about the patch's language regards other sorts of modifications.
Although unstated, it should be clear that data modifying
functions that are executed with a SELECT statement do modify data.
Where the patch is lacking is noting that schema alterations and FDW
modifications also have restrictions. I don't feel particularly
qualified regards where either are allowed, or not, although
I could probably get it right after some research.
Regards,
Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2013-08-07 00:27:13 | Re: Review: UNNEST (and other functions) WITH ORDINALITY |
Previous Message | Alvaro Herrera | 2013-08-06 22:32:21 | refactor heap_deform_tuple guts |