function side effects
in [PgSql]
|
From: Tom Lane on 23 Feb 2010 11:08 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Those classifications are meant as planner directives; they are >> NOT meant to be bulletproof. Hanging database integrity >> guarantees on whether a "non volatile" function changes anything >> is entirely unsafe. To give just one illustration of the >> problems, a nonvolatile function is allowed to call a volatile >> one. > Could it work to store a flag in each process to indicate when it is > executing a non-volatile function, and throw an error on any attempt > to call a volatile function or modify the database? It's *not an error* for a nonvolatile function to call a volatile one. At least it's never been in the past, and I'm sure you'd break some applications if you made it so in the future. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tatsuo Ishii on 23 Feb 2010 11:29 > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jaime Casanova on 23 Feb 2010 11:39 On Tue, Feb 23, 2010 at 11:08 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > It's *not an error* for a nonvolatile function to call a volatile one. it should be considered an error i think, someone think there is a use cas for calling volatile functions inside stable ones but i can see what that reason could be... > At least it's never been in the past, and I'm sure you'd break some > applications if you made it so in the future. > i'm sure of that too, but in this case seems reasonable to do so -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 23 Feb 2010 11:52 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: >> throw an error on any attempt to call a volatile function or >> modify the database? > It's *not an error* for a nonvolatile function to call a volatile > one. Right, we all know it currently doesn't throw an error, but I can't think of anywhere I'd like to have someone do that in a database for which I have any responsibility. Does anyone have a sane use case for a non-volatile function to call a volatile one or to update the database? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Stark on 23 Feb 2010 13:18
On Tue, Feb 23, 2010 at 4:52 PM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > Right, we all know it currently doesn't throw an error, but I can't > think of anywhere I'd like to have someone do that in a database for > which I have any responsibility. Does anyone have a sane use case > for a non-volatile function to call a volatile one or to update the > database? So consider for example a function which explicitly sets the timezone and then uses timestamp without timezone functions (which are volatile only because the GUC variable might change between calls). Or somebody who uses the tsearch functions because they're planning to not change their dictionaries. Or builds a hash function by calling random after setting the seed to a specific value -- this is actually a fairly popular strategy for building good hash functions. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |