function side effects
in [PgSql]
|
From: "Kevin Grittner" on 23 Feb 2010 13:39 Greg Stark <gsstark(a)mit.edu> wrote: > Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: >> 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). OK, I can see where that would be sane, but it seems more fragile than using timestamp with time zone. But, OK, something sane and functional could break on that. > Or somebody who uses the tsearch functions because they're > planning to not change their dictionaries. I didn't realize tsearch functions were volatile. Should they really be so? > 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. I'd never seen that. I'm not sure I understand where that comes in useful, but if you've seen it enough to call it "fairly popular" I guess I have to accept it. Thanks for the examples. They did make me consider a real-life type of process which isn't currently implemented as a PostgreSQL function, but conceivably could be -- randomizing a pool of jurors to facilitate jury selection. My eyes are opened. :-) -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:50 On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: >> Or somebody who uses the tsearch functions because they're >> planning to not change their dictionaries. > > I didn't realize tsearch functions were volatile. Should they > really be so? Uhm, my mistake. They're stable. Ok, for that one I'll substitute a function which uses pg_read_file knowing that the file in question won't be changed. Perhaps it's a per-machine key or something like that. >> 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. > > I'd never seen that. I'm not sure I understand where that comes in > useful, but if you've seen it enough to call it "fairly popular" I > guess I have to accept it. http://en.wikipedia.org/wiki/Universal_hashing They have the useful property that it's hard for an attacker to contrive data which has poor collision behaviour. > Thanks for the examples. They did make me consider a real-life type > of process which isn't currently implemented as a PostgreSQL > function, but conceivably could be -- randomizing a pool of jurors > to facilitate jury selection. My eyes are opened. :-) I'm not actually sure I follow what you're picturing. -- 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
From: Tom Lane on 23 Feb 2010 14:02 Greg Stark <gsstark(a)mit.edu> writes: > On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner > <Kevin.Grittner(a)wicourts.gov> wrote: >> I didn't realize tsearch functions were volatile. �Should they >> really be so? > Uhm, my mistake. They're stable. IMMUTABLE/STABLE/VOLATILE is not really about side effects, it is about how long the function value can be expected to hold still for. There are quite a lot of cases of functions that are marked conservatively as stable (or even volatile) but could be considered immutable in particular queries, because the application developer is prepared to assume that values such as GUCs won't change in his usage. The traditional way to deal with that is to wrap them in an immutable wrapper function. There's actually code in the planner to make that work --- we have to suppress inlining to avoid exposing the not-immutable guts, else the planner will not do what's wanted. There may be some value in inventing a "has no side effects" marker, but that should not be confused with IMMUTABLE/STABLE. 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: Robert Haas on 23 Feb 2010 15:01 On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > There may be some value in inventing a "has no side effects" marker, but > that should not be confused with IMMUTABLE/STABLE. Yeah, that's what I was thinking, too.... ....Robert -- 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 15:01
Greg Stark <gsstark(a)mit.edu> wrote: > Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: >> Thanks for the examples. They did make me consider a real-life >> type of process which isn't currently implemented as a PostgreSQL >> function, but conceivably could be -- randomizing a pool of >> jurors to facilitate jury selection. My eyes are opened. :-) > > I'm not actually sure I follow what you're picturing. Well, to facilitate people's rights to a jury of their peers, we obtain lists of people in each county based on having a drivers license or state ID, being registered to vote, etc., then (after eliminating duplicates and those who have served on juries in recent years) we randomly select a subset, who get questionnaires, from which (at a later date) we randomly pick people to summon for jury a juror panel, from which (on each day they appear) we randomly select people for particular juries. Any flaw in the randomness of selection could constitute grounds for an appeal of the outcome of a case, so we have to be careful about process. (Randomness being defined as the properties that nobody with an interest in the case can control or predict who will be selected from one group into the next, and there is no bias on anything related to demographics, like age or last name [which could correlate with ethnicity]). Sounds like fun, eh? -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 |