Re: Admin functions contrib
От | Andreas Pflug |
---|---|
Тема | Re: Admin functions contrib |
Дата | |
Msg-id | 4108E029.6060000@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: Admin functions contrib (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Admin functions contrib
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Admin functions contrib (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Bruce Momjian wrote: > I talked to Tom about this today. First, I want to apologize for > running you around in circles in this. I don't think we are giving it > the attention it needs because of our schedule. I also think the > functionality is drifting into the "new features" territory and this is > also part of the delay you are seeing. > > I think you did a great thing by breaking the patch into two parts: one > for logging, and the other for log reading and other stuff. The logging > part is already in the patch queue. As for the function below, I first > think the security issue brough up about them wasn't a valid concern > because as I stated someone could just load the plperl server-side > language and do anything to the OS. > > In fact this might be the best solution for you. Instead of trying to > code read/write/rename/unlink and other functions into the backend as > hardcoded, why not just have pgadmin load plperlu and as the super-user > you have access to that functionality, and much more, especially with > the new plperl in 7.5. In fact, your goal of modifying the > postgresql.conf file is much more natural in perl than in the API you > supplied, and probably more reliable. > > So, I suggest we get the logging code into the backend, and you can code > anything you want pgadmin to do in plperlu, and Win32 supports plperlu > too. The big advantage is that you can improve the plperlu functions > with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. What you're proposing is simply a nightmare. Actually, IMHO all functions should be *backend* code, not contrib code, even less arbitrary loadable language functions. Certainly an external package relying on a loadable language is quite the opposite, generating lots of support issues. It won't generate trust if pgadmin documentation advises "install untrusted plperl to maintain your machine". Additionally, several of the functions are by no means new, but replacements, did you notice pg_xxx_size? I posted this stuff as contrib module to keep it off the feature freeze issue. If it still can't go there, it must stay an external module which will be distributed as pgadmin add-on. Reimplementing it as plperlu is crap. Regards, Andreas
В списке pgsql-patches по дате отправления: