On Wed, Feb 20, 2008 at 01:43:46PM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
> >> For the point-and-drool crowd that can't cope with editing a text file,
> >> perhaps the best avenue to having a GUI is to build it atop the
> >> just-mentioned facility, namely
> >>
> >> 1. suck out the current settings.
> >> 2. provide a GUI that manipulates the values.
> >> 3. write back an entirely new postgresql.conf that doesn't take any
> >> trouble to preserve what was there before.
>
> > That's what we have now, and it basically forces each frontend to do the
> > implementatino themselevs. E.g. pgadmin has one implementation, phppgadmin
> > has another implementation, apparantly Greg has one implementation, there
> > may be third party ones out there with their own implementation.
>
> > The point is we need one implementatino that's in the server, because that
> > takes away redundancy and it makes it easier to maintain.
>
> The main part of that is the GUI, which is certainly not going to be in
> the server, so I fail to see exactly what you think you're really
> gaining.
The way things are now, writing the GUI is *simple* compared to the fact
that you have to write a config file parser. One for each tool.
The gain is exactly what I said above: we only need one implementation, not
one for each potential tool using it, and the maintenance is easier should
we ever decide to change how the config files are handled.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
