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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to