Re: [PATCH] Add transforms feature

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add transforms feature
Date: 2013-12-11 14:47:37
Message-ID: CA+TgmoZKQr8kd1kA67OOVnhFvzqcZfd-tWphFsZCbzEdqAYuyg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 11, 2013 at 9:19 AM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> On 12/11/2013 01:40 PM, Robert Haas wrote:
>> On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>> On Fri, 2013-12-06 at 11:28 +0100, Dimitri Fontaine wrote:
>>>>> Here is an idea. Add a GUC that basically says something like
>>>>> use_transforms = on|off. You can then attach that to individual
>>>>> functions, which is the right granularity, because only the function
>>>>> knows whether its code expects transforms or not. But you can use
>>>> the
>>>>> full power of GUC to configure it any way you want.
>>> Here is an updated patch that implements this, makes some of the
>>> documentation improvements that you suggested, and rebases everything.
>> I'm still kinda unimpressed by this. Behavior-changing GUC, uggh.
>>
> It should work ok if we could somehow check that the GUC is set
> on the function and fall back to session GUC in case it is not.
>
> Not sure if this is possible though.
>
> The need from this arises from calling other functions from a new func.
> At the moment if there is a new function defined as
>
> CREATE FUNCTION f_uses_xforms() AS $$ ... $$ SET use_transforms=on;
>
> calls a legacy function which will break if transforms are used then the
> _old_ function declaration needs to be modified to add (use_transforms=off)

Yeah, exactly.

> It is much easier than debugging/rewriting the function, but this is
> something I'd like us to be able to avoid.
>
> PS. maybe we could resurrect the WITH (attribute, ...) available in
> CREATE FUNCTION syntax for passing function-specific flags ?

It's a thought. Or you could put some annotation in the function
body, as we do in PL/pgsql with the #option syntax.

Of course, making everyone decorate their new functions with
references to the transforms they want to use isn't wonderful either,
but it might be good at least to have the option. You could allow the
use of all installed transforms by default, but let people say WITH
(transforms='') if they don't want to use them or WITH
(transforms='comma, separated, list') if the want to require certain
ones.

Unfortunately, that'll probably mean that virtually all portable code
for procedural languages has to include some form of this incantation,
just as any nearly any PL/pgsql function has to include SET
search_path = '' if it wants to be not trivially subvertable. It's
annoying to grow more such decoration, but the alternative seems to be
hoping that nobody wants to write portable code that uses non-core
types, and that doesn't seem better.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-12-11 14:50:38 Re: autovacuum_work_mem
Previous Message Simon Riggs 2013-12-11 14:43:38 Re: autovacuum_work_mem