* Magnus Hagander <magnus@hagander.net> [080219 10:39]:
> On Tue, Feb 19, 2008 at 10:34:26AM -0500, Aidan Van Dyk wrote:
> > > Are you suggesting we keep appending? So if I set the same parameter 100
> > > times, it would show up on 100 rows?
> >
> > In my opinion, absolutely. It's easy, safe, and the "overhead"
> > associated with it is minimal, and not in any critical path "work" path.
> > Add to that the fact that the admin can easily clean up the file any
> > time he wants too.
>
> I think that's entirely unworkable. While I absolutelyi don't want to break
> things for people who use the config file as the primary interface (heck,
> *I* am one of those people), it has to be usable for the case it's trying
> to fix. And this really wouldn't be.
Can you explain why this wouldn't be usable?
I see the following propeties:
*) KISS
*) Easily "function-able"
*) 0 cost on the server writing "new/changed" GUC settings (open/seek/write/close)
*) 0 cost on setting "permanent" settings via commands
*) 0 cost on PostgreSQL config code infrastructure
*) 0 cost on "running" database
*) minimal cost on "reading" config file (a few more lines)
This seems to be usable for everything the case it's trying to fix
wants:
*) simple, and guarenteed to work, not loosing any existing config file syntax
*) not hard to maintain/backport
*) not expensive to a running database cluster
*) "permanent" settings are saved/reloaded correctly
I don't see anything that would make this unusable for the purpose of
having the server be able to "permanently" save GUC settings.
A user using this interface isn't going to care if a file is 1 line,
or 100 lines, and whether the config file parsing (on startup or reload)
takes 13.34ms or 13.69ms.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
