Re: [PATCHES] PSQLRC environment variable.
Bruce Momjian wrote: Applied. Replace rename it to psqlrc instead of psql.rc. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] PSQLRC environment variable.
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I just checked a few apps and I see they usually allow a global config file to be specified. How about SYSPSQLRC that adds a system-wide psql config file to be read before the one in the home directory? The ones I know of that allow such a thing generally hard-wire the location of the global config file at build time, rather than taking it from an environment variable. The env var approach seems weird, and a tad inefficient (since you'd have to put such an env var into the global .profile, meaning it propagates into every single process ever launched on your system). Also I think we have at least one global config file already for libpq, and its location is hard-wired. Agreed. There is usually one global config file, and SYS* overrides it. The global one we have now is pg_service.conf. Maybe we should forget the environment variable idea and just have a pgsql.rc.sample file in share, with documentation in the file on how to install it. That is what we do with pg_service.conf now for libpq. The attached patch implements a global psql.rc file that is read before the one in the user's home directory --- doc changes included. It is configured just like pg_service.conf. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/ref/psql-ref.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.112 diff -c -c -r1.112 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 21 Apr 2004 00:34:18 - 1.112 --- doc/src/sgml/ref/psql-ref.sgml 21 Apr 2004 03:51:13 - *** *** 440,446 termoption--no-psqlrc//term listitem para ! Do not read the start-up file filename~/.psqlrc/filename. /para /listitem /varlistentry --- 440,447 termoption--no-psqlrc//term listitem para ! Do not read the start-up file filename/psql.rc/filename or ! filename~/.psqlrc/filename. /para /listitem /varlistentry *** *** 1859,1866 para The autocommit-on mode is productnamePostgreSQL/'s traditional behavior, but autocommit-off is closer to the SQL spec. If you !prefer autocommit-off, you may wish to set it in !your filename.psqlrc/filename file. /para /note /listitem --- 1860,1868 para The autocommit-on mode is productnamePostgreSQL/'s traditional behavior, but autocommit-off is closer to the SQL spec. If you !prefer autocommit-off, you may wish to set it in the system-wide ! filenamepsql.rc/filename or your ! filename.psqlrc/filename file. /para /note /listitem *** *** 2488,2496 listitem para Before starting up, applicationpsql/application attempts to ! read and execute commands from the file ! filename$HOME/.psqlrc/filename. It could be used to set up ! the client or the server to taste (using the command\set /command and commandSET/command commands). /para /listitem --- 2490,2501 listitem para Before starting up, applicationpsql/application attempts to ! read and execute commands from the the system-wide ! filenamepsql.rc/filename file and the ! filename$HOME/.psqlrc/filename file in the user's home ! directory. See filenamereplaceablePREFIX//share/psql.rc.sample/ ! for information on setting up the system-wide file. It could be used ! to set up the client or the server to taste (using the command\set /command and commandSET/command commands). /para /listitem Index: src/bin/psql/Makefile === RCS file: /cvsroot/pgsql-server/src/bin/psql/Makefile,v retrieving revision 1.40 diff -c -c -r1.40 Makefile *** src/bin/psql/Makefile 9 Mar 2004 19:47:05 - 1.40 --- src/bin/psql/Makefile 21 Apr 2004 03:51:14 - *** *** 15,21 REFDOCDIR= $(top_srcdir)/doc/src/sgml/ref ! override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) -DFRONTEND OBJS= command.o common.o help.o input.o stringutils.o mainloop.o copy.o \ startup.o prompt.o variables.o large_obj.o print.o describe.o \ --- 15,21 REFDOCDIR= $(top_srcdir)/doc/src/sgml/ref ! override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) -DFRONTEND -DSYSCONFDIR='$(sysconfdir)' OBJS= command.o common.o help.o input.o stringutils.o mainloop.o copy.o \ startup.o prompt.o variables.o large_obj.o
Re: [PATCHES] PSQLRC environment variable.
Bruce Momjian wrote: Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Uh, why is that a good idea? Well, suppose you want all your users to use the same psqlrc file. Instead of creating symlinks for every user, you can just set PSQLRC in /etc/profile and everyone gets it. ... but people who want to make their own .psqlrc can't? At least not till it occurs to them to unset PSQLRC? I don't really see the use-case here. James' stated problem of setting a default search_path could be If they want their own, the just unset PSQLRC in their .profile. handled at least as effectively through either PGOPTIONS or server-side GUC settings (postgresql.conf, or per-user or per-database variable settings). I'm not averse to inventing PSQLRC if there's actually some case it solves better than any of our existing mechanisms. But so far it seems like a solution desperately in search of a problem. I think most/all applications that look for a file in the user directory have either a global place they look too, or a way to control where to look for it. This seems pretty Unix standard, I think we should follow that. What if we allow the environment variable to specify a global file to read in addition to the home directory .psqlrc file? That seems even more useful. I just checked a few apps and I see they usually allow a global config file to be specified. How about SYSPSQLRC that adds a system-wide psql config file to be read before the one in the home directory? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PSQLRC environment variable.
Bruce Momjian [EMAIL PROTECTED] writes: I just checked a few apps and I see they usually allow a global config file to be specified. How about SYSPSQLRC that adds a system-wide psql config file to be read before the one in the home directory? The ones I know of that allow such a thing generally hard-wire the location of the global config file at build time, rather than taking it from an environment variable. The env var approach seems weird, and a tad inefficient (since you'd have to put such an env var into the global .profile, meaning it propagates into every single process ever launched on your system). Also I think we have at least one global config file already for libpq, and its location is hard-wired. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] PSQLRC environment variable.
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Uh, why is that a good idea? Well, suppose you want all your users to use the same psqlrc file. Instead of creating symlinks for every user, you can just set PSQLRC in /etc/profile and everyone gets it. ... but people who want to make their own .psqlrc can't? At least not till it occurs to them to unset PSQLRC? I don't really see the use-case here. James' stated problem of setting a default search_path could be If they want their own, the just unset PSQLRC in their .profile. handled at least as effectively through either PGOPTIONS or server-side GUC settings (postgresql.conf, or per-user or per-database variable settings). I'm not averse to inventing PSQLRC if there's actually some case it solves better than any of our existing mechanisms. But so far it seems like a solution desperately in search of a problem. I think most/all applications that look for a file in the user directory have either a global place they look too, or a way to control where to look for it. This seems pretty Unix standard, I think we should follow that. What if we allow the environment variable to specify a global file to read in addition to the home directory .psqlrc file? That seems even more useful. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] PSQLRC environment variable.
In the tradition of telnet, xinit, and others, I've created a patch which
allows users to override the location of .psqlrc by setting the PSQLRC
environment variable. I occurs to me that you have probably considered this
and the fact that it is not implemented suggests that you have rejected the
idea, but I needed it and I figured it couldn't hurt to pass it along.
PSQLRC overrides $HOME/.psqlrc and, as with $HOME/.psqlrc, if there is an
error accessing the file, the function just returns having done nothing.
Cheers,
/jtt
[EMAIL PROTECTED]
Index: startup.c
===
RCS file: /src/cvs/postgres/src/bin/psql/startup.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 startup.c
--- startup.c 16 Dec 2003 22:15:32 - 1.1.1.4
+++ startup.c 7 Mar 2004 15:15:54 -
@@ -561,7 +561,12 @@
#ifdef WIN32
#define R_OK 0
#endif
-
+ if ((psqlrc = getenv(PSQLRC)))
+ {
+ if (access(psqlrc, R_OK) == 0)
+ process_file(psqlrc);
+ return;
+ }
/* Look for one in the home dir */
home = getenv(HOME);
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] PSQLRC environment variable.
Seems like a nice feature to me.
---
James Tanis wrote:
In the tradition of telnet, xinit, and others, I've created a patch which
allows users to override the location of .psqlrc by setting the PSQLRC
environment variable. I occurs to me that you have probably considered this
and the fact that it is not implemented suggests that you have rejected the
idea, but I needed it and I figured it couldn't hurt to pass it along.
PSQLRC overrides $HOME/.psqlrc and, as with $HOME/.psqlrc, if there is an
error accessing the file, the function just returns having done nothing.
Cheers,
/jtt
[EMAIL PROTECTED]
Index: startup.c
===
RCS file: /src/cvs/postgres/src/bin/psql/startup.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 startup.c
--- startup.c 16 Dec 2003 22:15:32 - 1.1.1.4
+++ startup.c 7 Mar 2004 15:15:54 -
@@ -561,7 +561,12 @@
#ifdef WIN32
#define R_OK 0
#endif
-
+ if ((psqlrc = getenv(PSQLRC)))
+ {
+ if (access(psqlrc, R_OK) == 0)
+ process_file(psqlrc);
+ return;
+ }
/* Look for one in the home dir */
home = getenv(HOME);
---(end of broadcast)---
TIP 8: explain analyze is your friend
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] PSQLRC environment variable.
James Tanis [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Tom Lane avows: Uh, why is that a good idea? As you will see, it takes a pretty contrived situation, but indeed I've got one :-) I have a software system which can use postgres if the user so wishes. We have a wrapper program for psql which logs in the caller to the database using stored values from another file. I wanted also to be able to set the search path so that everyone wouldn't have to constantly prepend our schema name to our table names in order to view our tables, so that immediatly suggested using .psqlrc. I do *not* however want to override (or overwrite) any .psqlrc they might have, neither do I want to *create* one if they don't have one since we call exec psql at the end of the wrapper and thus cannot clean it up. So if they do not have a $HOME/.psqlrc, I create one in a tmp directory inside of the directory tree where our software lives and set PSQLRC to point at it. It doesn't matter that we can't clean it up because it lives in our space (as it were). But if they do have their own .psqlrc, doesn't that mean that you fail to apply the change you need? It seems like this mechanism doesn't achieve the results you actually want. Wouldn't setting search_path via PGOPTIONS be as effective if not more so? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] PSQLRC environment variable.
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Uh, why is that a good idea? Well, suppose you want all your users to use the same psqlrc file. Instead of creating symlinks for every user, you can just set PSQLRC in /etc/profile and everyone gets it. ... but people who want to make their own .psqlrc can't? At least not till it occurs to them to unset PSQLRC? I don't really see the use-case here. James' stated problem of setting a default search_path could be handled at least as effectively through either PGOPTIONS or server-side GUC settings (postgresql.conf, or per-user or per-database variable settings). I'm not averse to inventing PSQLRC if there's actually some case it solves better than any of our existing mechanisms. But so far it seems like a solution desperately in search of a problem. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
