> 20 апр. 2021 г., в 02:38, Stephen Frost <sfrost@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
exploitingtimestamp overflow, but I doubt it's practically usable.
Thanks!
Best regards, Andrey Borodin.
[0]
https://github.com/ivan816/simple-1c/blob/f2e5ce78b98f70f30039fd3de79308a59d432fc2/Simple1C/Impl/Sql/SchemaMapping/Simple1cSchemaCreator.cs#L74
