Re: [PATCH] Add transforms feature

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add transforms feature
Date: 2015-03-12 12:12:23
Message-ID: CAFj8pRCd7pzLq6yQSMjv2H6zrA0W9aVVeZkwjaqE1SA9CNBKuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

I am looking to code.

Some small issues:

1. fix missing semicolon pg_proc.h

Oid protrftypes[1]; /* types for which to apply
transforms */

2. strange load lib by in sql scripts:

DO '' LANGUAGE plperl;
SELECT NULL::hstore;

use load plperl; load hstore; instead

3. missing documentation for new contrib modules,

4. pg_dump - wrong comment

+<-----><------>/*
+<-----><------> * protrftypes was added at v9.4
+<-----><------> */

4. Why guc-use-transforms? Is there some possible negative side effect of
transformations, so we have to disable it? If somebody don't would to use
some transformations, then he should not to install some specific
transformation.

5. I don't understand to motivation for introduction of protrftypes in
pg_proc and TRANSFORM clause for CREATE FUNCTION - it is not clean from
documentation, and examples in contribs works without it. Is it this
functionality really necessary? Missing tests, missing examples.

Regards

Pavel

2015-03-08 16:34 GMT+01:00 Peter Eisentraut <peter_e(at)gmx(dot)net>:

> On 3/6/15 9:56 AM, Pavel Stehule wrote:
> > Hi
> >
> > I am checking this patch, but it is broken still
>
> Here is an updated patch.
>
> (Note that because of the large pg_proc.h changes, it is likely to get
> outdated again soon. But for reviewing, you can always apply it against
> an older version of master.)
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sawada Masahiko 2015-03-12 12:15:14 Re: Proposal : REINDEX xxx VERBOSE
Previous Message Greg Stark 2015-03-12 11:16:55 Re: Precedence of standard comparison operators