Re: our checks for read-only queries are not great

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 9, 2020 at 3:07 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> You could argue about exactly how to extend that to non-spec
>> utility commands, but for the most part allowing them seems
>> to make sense if DML is allowed.

> But I think we allow them on all tables, not just temp tables, so I
> don't think I understand this argument.

Oh, I misunderstood your concern.

Peter might remember more clearly, but I have a feeling that we
concluded that the intent of the spec was for read-only-ness to
disallow globally-visible changes in the visible database contents.
VACUUM, for example, does not cause any visible change, so it
should be admissible. REINDEX ditto. (We ignore here the possibility
of such things causing, say, a change in the order in which rows are
returned, since that's beneath the spec's notice to begin with.)
ANALYZE ditto, except to the extent that if you look at pg_stats
you might see something different --- but again, system catalog
contents are outside the spec's purview.

You could extend this line of argument, perhaps, far enough to justify
ALTER SYSTEM SET as well. But I don't like that because some GUCs have
visible effects on the results that an ordinary query minding its own
business can get. Timezone is perhaps the poster child there, or
search_path. If we were to subdivide the GUCs into "affects
implementation details only" vs "can affect query semantics",
I'd hold still for allowing ALTER SYSTEM SET on the former group.
Doubt it's worth the trouble to distinguish, though.

regards, tom lane