Greetings,
* Andrey Borodin (x4mmm@yandex-team.ru) wrote:
> > 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.
Erm, it's very clearly not leakproof and will happily return information
about the value passed in during some error cases...
Thanks,
Stephen
