Re: [PATCH] Add transforms feature

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add transforms feature
Date: 2013-07-08 19:00:16
Message-ID: 51DB0C40.9050705@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter,

On 07/07/2013 12:06 PM, Peter Eisentraut wrote:
> Good point. My original patch allowed func(sql_type) -> internal, but I
> took that out because people had security concerns.
>
> I'd be OK with restricting transform creation to superusers in the first
> cut.

Have we added the ability of non-superusers to create extensions yet?
Until we have that, there's no point in allowing them to load
transforms. Once we have that, we'll need to let them do it.

>>> We need the dependencies, because otherwise dropping a transform would
>>> break or silently alter the behavior of functions that depend on it.
>>> That sounds like my worst nightmare, thinking of some applications that
>>> would be affected by that. But your point is a good one. I think this
>>> could be addressed by prohibiting the creation of a transform that
>>> affects functions that already exist.
>>
>> However I don't see this prohibition of create transform if there is
>> already such function. You are not planning to address this issue?
>
> I had planned to implement that, but talking to some people most didn't
> think it was useful or desirable. It's still open for debate.

I don't think it's desirable. It would be hard to do, and at some level
we need to make a presumption of competence on the part of the DBA. We
should put a warning in the docs, though.

>> (b) we can expect maybe a dozen to 18 of them in core based on the data
>> types there, and I hate to clutter up /contrib, and
>
> Well, that's a matter of opinion. I'd be more happy with 250 contribs
> all on the same level versus a bunch of subdirectories structured based
> on personal preferences.
>
> But hey, we disagreed on config.sgml for similar reasons, IIRC. ;-)

Yeah, I'd like to see some other opinions on this.

>> (c) I'd like to do a future feature which supports "install all
>> transforms" functionality, which would be helped by having them in their
>> own directory.
>
> Installing all transforms by itself is not a sensible operation, because
> you only want the transforms for the types and languages that you
> actually use or have previously selected for installation.

Give me some credit. I'm talking about a script for "install all
transforms for which the dependancies are already installed". That's
certainly entirely doable, and would be made easier by putting the
transforms in their own directory or otherwise flagging them to identify
them as transforms.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-07-08 19:09:25 Re: Changing recovery.conf parameters into GUCs
Previous Message Peter Geoghegan 2013-07-08 18:59:27 Re: pg_filedump 9.3: checksums (and a few other fixes)