From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allowing to create LEAKPROOF functions to non-superuser |
Date: | 2021-04-25 11:10:35 |
Message-ID: | C4C001D8-6C68-4411-834D-1D3C0ADE3796@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 20 апр. 2021 г., в 02:38, Stephen Frost <sfrost(at)snowman(dot)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.
Thanks!
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-04-25 13:36:21 | Re: Use simplehash.h instead of dynahash in SMgr |
Previous Message | Noah Misch | 2021-04-25 10:24:19 | Re: Allowing to create LEAKPROOF functions to non-superuser |