> [EMAIL PROTECTED] wrote: >> > Obviously, we need to do something. There are just too many people >> who >> > want improvement in this area. The question is what changes to make. >> > >> > My personal opinion is that we move the config files in /data/etc, and >> > allow admins to move that directory somewhere else with symlinks. If >> we >> > want to add #include capability too, that would help things. >> > >> >> I wish I could impress on you the distaste the average admin has for >> symlinks. If you knew how much DBAs and sys-admins hated symlinks, you >> wouldn't think of them as a solution. To most, a symlink is used when >> the >> software has no other viable option. When and admin needs to use a >> symlink >> to configure software, they view this as a cop-out. > > Let me tell you the compromise I thought of. > > First, we put the config files (postgresql.conf, pg_hba.conf, > pg_ident.conf) in data/etc by default.
What does that really give you? > > Then, we could add an initdb option to put the config files in another > location. If you choose that, the config files are put into that new > directory, and a symlink is created in /data/etc to point to that new > location. Symlinks don't go with an scp. This is frustrating. Please take no offense by this, symlinks do not always act exactly like files. Most of the time they do, but every now and then, depending on the application or utilities used, symlinks get copied with invalid links or ignored alltogether. IMHO, the PostgreSQL team depends too much on symlinks as a bandaid to real defects and issues. I would prefer to be able to configure a system without symlinks. Sysadmins and DBAs do not like symlinks. Any "solution" based on symlinks will be used grudgingly. > > That way, you can centralize all your config files under one central > directory, you can find and back them up easily, and the /data directory > contains a symlink pointing to the config directory so you don't need to > specify a separate config directory on the command line. I would like to ask you, why does there need to be a compromise? (I am not oppsed to compromise, but you are relying on symlinks again, and this is a problem. ) (1) The code is written. (2) The code is working. (3) The code does not affect current default behavior. (4) I am willing to change to fit any coding standards which may be an issue. It makes no sense to me to write something new as a compromise, when I already have something that works, is (obviously) already what I want, and does not, in fact, change any default PostgreSQL behavior. Take a look at the patch, I submitted it about a year or so ago, and it was rejected in favor of a redesign peter was going to do. Needless to say that was not done. This is such a *little* thing (The patch is only 760 lines), I can't believe it is so difficult, I simply do not understand the opposition to it, not then and not now. Could someone please tell me why this is bad? I "get it" that people on this group don't want to do it this way, but what is *wrong*, and by wrong, I mean harmful to PostgreSQL, about it? No one that does not like this functionality would ever even be inconvenienced by it. Those of us who want it, would find it more convenient. Could someone please tell me why this is such a fight? I've been maintaining this patch for well over year now, it spans two major versions, and I have people downloading it from my site every month. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
