On Wed, Feb 20, 2008 at 03:02:49PM -0800, Josh Berkus wrote:
> All,
>
> I think we're failing to discuss the primary use-case for this, which
> is one reason why the solutions aren't obvious.
>
> And that use case is: multi-server management.
I don't agree that this is the primary use case. But I do agree that it's
one.
> PostgreSQL is *easy* to manage on one server. For a single server, the
> existing text file editor GUIs are clunky but good enough.
Agreed.
> Now, none of this requires managing the settings via the SQL command
> line. Since we need to make it network-accessable, though, that seems
> the easiest route. Otherwise, we'd have to set up a daemon running on
> a 2nd port.
Not just a 2nd port. A second security and authenticatino system.
Supporting all the authentication methods the backend does (we can't just
say "you can use gssapi/kerberos to increase your security, and TLS to
prevent sniffing. Oh, but to make configuration changes, it's plaintext
passwords over unencrypted connection")
A second daemon and a second protocol is just plain stupid. We have a
perfectly good framework to build it on inside the current protocol.
> P.S. I don't care what the syntax is.
+1. Probably the best way is a function, because that's least invasive, and
easiest to change.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
