Tom Lane wrote:
> There's an ancient saying "I can make this code arbitrarily fast ...
> if it doesn't have to give the right answer". I think that applies
> here. Fast and unsafe is not how the Postgres project customarily
> designs things.
I'm missing something, that's clear. Because I can't see why the PL/Java
way of doing it is anything but both fast and 100% safe. I agree 100%
that unsafe is not an option.
I'm arguing that since my design is totally safe, intuitive, and cover
90% of the use-cases, it is the best one.
Regards,
Thomas Hallgren
PS.
The current design that prevents non-volatile functions from doing
things with side effects is not very safe ;-) I persist claiming that
there's a better (and safe) way to handle that.