Re: Extension Templates S03E11
От | Stephen Frost |
---|---|
Тема | Re: Extension Templates S03E11 |
Дата | |
Msg-id | 20131126022244.GM17272@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Extension Templates S03E11 (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
* Heikki Linnakangas (hlinnakangas@vmware.com) wrote: > On 24.11.2013 00:19, Dimitri Fontaine wrote: > >This patch has received extensive review in July and I think it now > >properly implements the design proposed by Tom and Heikki in 9.3/CF4. > > Ok, since my name has been mentioned, I'll bite.. > > I still don't like this. What I suggested back in December was to > have a simple mechanism to upload an extension zip file to the > server via libpq > (http://www.postgresql.org/message-id/50BF80A6.20500@vmware.com). > The idea developed from that into the concept of extension > templates, but the original idea was lost somewhere along the way. I hate to admit it, but I kind of agree.. While reviewing the patch and thinking about it, the whole thing really did start to strike me as a little too 'meta'. We want a way to package and ship extensions which can then be loaded via the libpq protocol. I'm not sure that there's really any need to track all of this in catalog tables. Also as part of the patch review, I went back and looked through some of the older threads around this and noticed the understandable concern, given the current patch, of non-superusers being able to create extension templates. I'm not sure that an approach which allows a zip file to be uploaded would be something we could allow non-superusers to do, but I really feel like we need a way for non-superusers to create extensions (when they don't have untrusted-language components). Now, given these two trains of thought, I start to see that we may want to avoid non-superusers being able to create arbitrary files on disk, even in a controlled area. We've managed that for various other objects (tables, et al), I'm sure we could work out a solution to that issue... Thanks, Stephen
В списке pgsql-hackers по дате отправления: