> > I was talking about this to someone in Cuba and one conclusion we
> > reached was that this was a fairly difficult task -- consider that
> > someone may choose to define an innocent-looking operator using a
> > volatile function. If you only examine things that look like functions
> > in the query you will miss those. The only way to figure out whether a
> > query has a write effect is to ask the server about the whole query.
>
> In general you are right. However in most database application
> systems, it is possible that all functions are properly designed and
> implemented (at least they want so). In this world, more or less
> PostgreSQL functions are just a part of their applications. If they
> trust their client side applications, why they cannot trust PostgreSQL
> custom functions as well?
Still there could be "none honest functions" such as calling volatile
functions from non volatile function in the PostgreSQL system(I have
not made any investigation. But it's possible). Or vendor provided
functions (for example embedded in closed source packages) might fall
into this category. Probably it's enough for pgpool to have a "black
list" of such that function. Maintaining such a list is a boring task
but I cannot think of any good way at this point.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp