Greg Stark <gsst...@mit.edu> wrote: > Kevin Grittner <kevin.gritt...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
