Re: Allowing to create LEAKPROOF functions to non-superuser

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.

[0] https://github.com/ivan816/simple-1c/blob/f2e5ce78b98f70f30039fd3de79308a59d432fc2/Simple1C/Impl/Sql/SchemaMapping/Simple1cSchemaCreator.cs#L74

In response to

Responses

Browse pgsql-hackers by date

  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