Greg Stark <gsstark(at)mit(dot)edu> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)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