Re: [PATCH] Add transforms feature

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: [PATCH] Add transforms feature
Дата
Msg-id 51DB0C40.9050705@agliodbs.com
обсуждение исходный текст
Ответ на Re: transforms  (Peter Eisentraut <peter_e@gmx.net>)
Список 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



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: pg_filedump 9.3: checksums (and a few other fixes)
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Changing recovery.conf parameters into GUCs