Greetings, * Andrey Borodin (x4...@yandex-team.ru) wrote: > > 20 апр. 2021 г., в 02:38, Stephen Frost <sfr...@snowman.net> написал(а): > > Here's what I'd ask Andrey- what's the actual use-case here? Are these > > cases where users are actually adding new functions which they believe > > are leakproof where those functions don't require superuser already to > > be created? Clearly if they're in a untrusted language and you have to > > be a superuser to install them in the first place then they should just > > mark the function as leakproof when they install it. If these are > > trusted language functions, I'd be curious to actually see them as I > > have doubts about if they're actually leakproof.. > > > > Or is the actual use-case here that they just want to mark functions we > > know aren't leakproof as leakproof anyway because they aren't getting > > the performance they want? > > > > If it's the latter, as I suspect it is, then I don't really think the > > use-case justifies any change on our part- the right answer is to make > > those functions actually leakproof, or write ones which are. > > Customer was restoring pg_dump of on-premise ERP known as 1C (something like > TurboTax) with this add-on [0] > > CREATE FUNCTION simple1c.date_from_guid(varchar(36)) RETURNS timestamp > LANGUAGE plpgsql IMMUTABLE LEAKPROOF STRICT > > I'm not 1C-expert (programmed it a bit to get few bucks when I was a > student), but seems like this function simple1c.date_from_guid() can be used > in DSL queries. It have no obvious side effects. Maybe we could hack it by > exploiting timestamp overflow, but I doubt it's practically usable.
Erm, it's very clearly not leakproof and will happily return information about the value passed in during some error cases... Thanks, Stephen
signature.asc
Description: PGP signature
