Re: [PATCH] Add transforms feature

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [PATCH] Add transforms feature
Дата
Msg-id 1389838398.7436.1.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: [PATCH] Add transforms feature  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: [PATCH] Add transforms feature  (Andres Freund <andres@2ndquadrant.com>)
Список 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. ;-)



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance