Re: [PATCH] Add transforms feature

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add transforms feature
Date: 2014-01-16 02:13:18
Message-ID: 1389838398.7436.1.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Fri, 2014-01-10 at 22:46 -0500, Peter Eisentraut wrote:
> On Wed, 2013-12-11 at 09:47 -0500, Robert Haas wrote:
> > 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.
>
> I'll try to implement something like that.

So it turns out the SQL standard actually specifies it more or less that
way.

What I have implemented now is that you can attach a clause TRANSFORM
{ ALL | NONE | FOR TYPE xxx, ... } to CREATE FUNCTION, which is recorded
in pg_proc, so there is no interference by run-time parameters. I kept
the use_transforms parameter to set the default value (again, at CREATE
FUNCTION time). pg_dump never dumps TRANSFORM ALL, always the resolved
type list, so you get the exact behavior back after restores or
upgrades.

The only place where this currently breaks is SPI calls inside
functions, because CREATE FUNCTION doesn't know about them. That can be
worked around by providing an explicit type list, but that would in turn
interfere with what you want to do with the parameter list. Also, there
is no way to attach a TRANSFORM clause to inline calls (DO).

The attached patch will probably fail to apply because of the pg_proc
changes. So if you want to try it out, look into the header for the Git
hash it was based off. I'll produce a properly merged version when this
approach is validated. Also, some implementation details could probably
take some revising after a couple of nights of sleep. ;-)

Attachment Content-Type Size
transforms-v2014-01.1.patch.gz application/x-gzip 107.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-01-16 02:37:16 Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Previous Message Jan Kara 2014-01-16 01:41:34 Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance