Thread: 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
jtt@sysd.com
----------------------------------------------------------------
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 -0000 1.1.1.4
+++ startup.c 7 Mar 2004 15:15:54 -0000
@@ -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");
James Tanis <jtt@sysd.com> writes:
> 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.
Uh, why is that a good idea?
regards, tom lane
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
> jtt@sysd.com
>
>
> ----------------------------------------------------------------
> 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 -0000 1.1.1.4
> +++ startup.c 7 Mar 2004 15:15:54 -0000
> @@ -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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote: > James Tanis <jtt@sysd.com> writes: > > 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. > > 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
James Tanis <jtt@sysd.com> writes:
> In message <154.1078876735@sss.pgh.pa.us>, 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
Bruce Momjian <pgman@candle.pha.pa.us> 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
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> 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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
In message <154.1078876735@sss.pgh.pa.us>, Tom Lane avows: %--- Begin Cite ---% > James Tanis <jtt@sysd.com> writes: > > In the tradition of telnet, xinit, and others, I've created a patch wh > ich > > allows users to override the location of .psqlrc by setting the PSQLRC > > environment variable. > > 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). I imagine I probably lost you somewhere since I'm pretty bad at explaining these things and apologize for that. I certainly would not consider this anything beyond a minor enhancement and as I said in my original mail, I wouldn't be surprised if y'all thought it wasn't worthwhile. Cheers, /jtt > > regards, tom lane %--- End Cite ---%
In message <2319.1078893158@sss.pgh.pa.us>, Tom Lane avows: %--- Begin Cite ---% > 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 If they have their own, then I trust them to do what they want (ie they can then add the set search_path themselves). > achieve the results you actually want. Wouldn't setting search_path via > PGOPTIONS be as effective if not more so? Ah! Perhaps. I'm actually not our postgres guy. I actually work on the core part of our software. I just got the job of trying to put it all together and .psqlrc hack seemed a reasonable way of accomplishing something I thought was useful. However the point of allowing a site to make /etc/psqlrc the global psqlrc isn't a bad one too (and I even came up with this a couple of days ago -- don't know why I forgot to mention it....) although I guessing that the site could set PGOPTIONS globally as easily as they could set PSQLRC. OTOH, there certainly is something to be said simply for the following: it's a very simple hack which fits in nicely in the code. It provides an option to postgres users which someone out there might find useful even if we can't come up with a convincing argument right now. It seems to me that when I first got into sysadmin games back in the late '80's, this was the prevailing attitude. But I certainly look into the PGOPTIONS thing; I'd prefer not to have to support any local hacks if I don't have to :-) Cheers, /jtt > > regards, tom lane %--- End Cite ---%
Bruce Momjian wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> 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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> 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
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> 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 pgman@candle.pha.pa.us | (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 -0000 1.112 --- doc/src/sgml/ref/psql-ref.sgml 21 Apr 2004 03:51:13 -0000 *************** *** 440,446 **** <term><option>--no-psqlrc</></term> <listitem> <para> ! Do not read the start-up file <filename>~/.psqlrc</filename>. </para> </listitem> </varlistentry> --- 440,447 ---- <term><option>--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 <productname>PostgreSQL</>'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 <productname>PostgreSQL</>'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 ! <filename>psql.rc</filename> or your ! <filename>.psqlrc</filename> file. </para> </note> </listitem> *************** *** 2488,2496 **** <listitem> <para> Before starting up, <application>psql</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 <command>SET</command> commands). </para> </listitem> --- 2490,2501 ---- <listitem> <para> Before starting up, <application>psql</application> attempts to ! read and execute commands from the the system-wide ! <filename>psql.rc</filename> file and the ! <filename>$HOME/.psqlrc</filename> file in the user's home ! directory. See <filename><replaceable>PREFIX</>/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 <command>SET</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 -0000 1.40 --- src/bin/psql/Makefile 21 Apr 2004 03:51:14 -0000 *************** *** 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 print.o describe.o \ *************** *** 50,55 **** --- 50,56 ---- install: all installdirs $(INSTALL_PROGRAM) psql$(X) $(DESTDIR)$(bindir)/psql$(X) + $(INSTALL_DATA) $(srcdir)/psql.rc.sample $(DESTDIR)$(datadir)/psql.rc.sample installdirs: $(mkinstalldirs) $(DESTDIR)$(bindir) Index: src/bin/psql/startup.c =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/psql/startup.c,v retrieving revision 1.88 diff -c -c -r1.88 startup.c *** src/bin/psql/startup.c 19 Apr 2004 17:42:58 -0000 1.88 --- src/bin/psql/startup.c 21 Apr 2004 03:51:15 -0000 *************** *** 44,50 **** */ PsqlSettings pset; ! #define PSQLRC ".psqlrc" /* * Structures to pass information between the option parsing routine --- 44,51 ---- */ PsqlSettings pset; ! #define PSQLRC ".psqlrc" ! #define SYSPSQLRC "psql.rc" /* * Structures to pass information between the option parsing routine *************** *** 74,79 **** --- 75,81 ---- static void parse_psql_options(int argc, char *argv[], struct adhoc_opts * options); static void process_psqlrc(void); + static void process_psqlrc_file(char *filename); static void showVersion(void); #ifdef USE_SSL *************** *** 562,567 **** --- 564,572 ---- } + #ifndef SYSCONFDIR + #error "You must compile this file with SYSCONFDIR defined." + #endif /* *************** *** 570,601 **** static void process_psqlrc(void) { ! char *psqlrc; char *home; #if defined(WIN32) && (!defined(__MINGW32__)) #define R_OK 4 #endif ! /* Look for one in the home dir */ ! home = getenv("HOME"); ! ! if (home) ! { ! psqlrc = pg_malloc(strlen(home) + 1 + strlen(PSQLRC) + 1 + ! strlen(PG_VERSION) + 1); ! sprintf(psqlrc, "%s/%s-%s", home, PSQLRC, PG_VERSION); ! if (access(psqlrc, R_OK) == 0) ! process_file(psqlrc); ! else ! { ! sprintf(psqlrc, "%s/%s", home, PSQLRC); ! if (access(psqlrc, R_OK) == 0) ! process_file(psqlrc); ! } ! free(psqlrc); ! } } --- 575,613 ---- static void process_psqlrc(void) { ! char *globalFile = SYSCONFDIR "/" SYSPSQLRC; char *home; + char *psqlrc; + + process_psqlrc_file(globalFile); + + if ((home = getenv("HOME")) != NULL) + { + psqlrc = pg_malloc(strlen(home) + 1 + strlen(PSQLRC) + 1); + sprintf(psqlrc, "%s/%s", home, PSQLRC); + process_psqlrc_file(psqlrc); + } + } + + + + static void + process_psqlrc_file(char *filename) + { + char *psqlrc; #if defined(WIN32) && (!defined(__MINGW32__)) #define R_OK 4 #endif ! psqlrc = pg_malloc(strlen(filename) + 1 + strlen(PG_VERSION) + 1); ! sprintf(psqlrc, "%s-%s", filename, PG_VERSION); ! if (access(psqlrc, R_OK) == 0) ! process_file(psqlrc); ! else if (access(filename, R_OK) == 0) ! process_file(filename); ! free(psqlrc); }
Applied. --------------------------------------------------------------------------- Bruce Momjian wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> 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 > pgman@candle.pha.pa.us | (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 -0000 1.112 > --- doc/src/sgml/ref/psql-ref.sgml 21 Apr 2004 03:51:13 -0000 > *************** > *** 440,446 **** > <term><option>--no-psqlrc</></term> > <listitem> > <para> > ! Do not read the start-up file <filename>~/.psqlrc</filename>. > </para> > </listitem> > </varlistentry> > --- 440,447 ---- > <term><option>--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 <productname>PostgreSQL</>'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 <productname>PostgreSQL</>'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 > ! <filename>psql.rc</filename> or your > ! <filename>.psqlrc</filename> file. > </para> > </note> > </listitem> > *************** > *** 2488,2496 **** > <listitem> > <para> > Before starting up, <application>psql</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 <command>SET</command> commands). > </para> > </listitem> > --- 2490,2501 ---- > <listitem> > <para> > Before starting up, <application>psql</application> attempts to > ! read and execute commands from the the system-wide > ! <filename>psql.rc</filename> file and the > ! <filename>$HOME/.psqlrc</filename> file in the user's home > ! directory. See <filename><replaceable>PREFIX</>/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 <command>SET</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 -0000 1.40 > --- src/bin/psql/Makefile 21 Apr 2004 03:51:14 -0000 > *************** > *** 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 print.o describe.o \ > *************** > *** 50,55 **** > --- 50,56 ---- > > install: all installdirs > $(INSTALL_PROGRAM) psql$(X) $(DESTDIR)$(bindir)/psql$(X) > + $(INSTALL_DATA) $(srcdir)/psql.rc.sample $(DESTDIR)$(datadir)/psql.rc.sample > > installdirs: > $(mkinstalldirs) $(DESTDIR)$(bindir) > Index: src/bin/psql/startup.c > =================================================================== > RCS file: /cvsroot/pgsql-server/src/bin/psql/startup.c,v > retrieving revision 1.88 > diff -c -c -r1.88 startup.c > *** src/bin/psql/startup.c 19 Apr 2004 17:42:58 -0000 1.88 > --- src/bin/psql/startup.c 21 Apr 2004 03:51:15 -0000 > *************** > *** 44,50 **** > */ > PsqlSettings pset; > > ! #define PSQLRC ".psqlrc" > > /* > * Structures to pass information between the option parsing routine > --- 44,51 ---- > */ > PsqlSettings pset; > > ! #define PSQLRC ".psqlrc" > ! #define SYSPSQLRC "psql.rc" > > /* > * Structures to pass information between the option parsing routine > *************** > *** 74,79 **** > --- 75,81 ---- > static void parse_psql_options(int argc, char *argv[], > struct adhoc_opts * options); > static void process_psqlrc(void); > + static void process_psqlrc_file(char *filename); > static void showVersion(void); > > #ifdef USE_SSL > *************** > *** 562,567 **** > --- 564,572 ---- > > } > > + #ifndef SYSCONFDIR > + #error "You must compile this file with SYSCONFDIR defined." > + #endif > > > /* > *************** > *** 570,601 **** > static void > process_psqlrc(void) > { > ! char *psqlrc; > char *home; > > #if defined(WIN32) && (!defined(__MINGW32__)) > #define R_OK 4 > #endif > > ! /* Look for one in the home dir */ > ! home = getenv("HOME"); > ! > ! if (home) > ! { > ! psqlrc = pg_malloc(strlen(home) + 1 + strlen(PSQLRC) + 1 + > ! strlen(PG_VERSION) + 1); > ! sprintf(psqlrc, "%s/%s-%s", home, PSQLRC, PG_VERSION); > > ! if (access(psqlrc, R_OK) == 0) > ! process_file(psqlrc); > ! else > ! { > ! sprintf(psqlrc, "%s/%s", home, PSQLRC); > ! if (access(psqlrc, R_OK) == 0) > ! process_file(psqlrc); > ! } > ! free(psqlrc); > ! } > } > > > --- 575,613 ---- > static void > process_psqlrc(void) > { > ! char *globalFile = SYSCONFDIR "/" SYSPSQLRC; > char *home; > + char *psqlrc; > + > + process_psqlrc_file(globalFile); > + > + if ((home = getenv("HOME")) != NULL) > + { > + psqlrc = pg_malloc(strlen(home) + 1 + strlen(PSQLRC) + 1); > + sprintf(psqlrc, "%s/%s", home, PSQLRC); > + process_psqlrc_file(psqlrc); > + } > + } > + > + > + > + static void > + process_psqlrc_file(char *filename) > + { > + char *psqlrc; > > #if defined(WIN32) && (!defined(__MINGW32__)) > #define R_OK 4 > #endif > > ! psqlrc = pg_malloc(strlen(filename) + 1 + strlen(PG_VERSION) + 1); > ! sprintf(psqlrc, "%s-%s", filename, PG_VERSION); > > ! if (access(psqlrc, R_OK) == 0) > ! process_file(psqlrc); > ! else if (access(filename, R_OK) == 0) > ! process_file(filename); > ! free(psqlrc); > } > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Applied. Replace rename it to psqlrc instead of psql.rc.
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Applied. > > Replace rename it to psqlrc instead of psql.rc. Yea, I debated psql.rc and psqlrc, but chose psql.rc. If you like psqlrc better, that's fine with me. Patch attached and applied. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (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.113 diff -c -c -r1.113 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 22 Apr 2004 01:53:17 -0000 1.113 --- doc/src/sgml/ref/psql-ref.sgml 22 Apr 2004 14:06:21 -0000 *************** *** 440,446 **** <term><option>--no-psqlrc</></term> <listitem> <para> ! Do not read the start-up file <filename>/psql.rc</filename> or <filename>~/.psqlrc</filename>. </para> </listitem> --- 440,446 ---- <term><option>--no-psqlrc</></term> <listitem> <para> ! Do not read the start-up file <filename>/psqlrc</filename> or <filename>~/.psqlrc</filename>. </para> </listitem> *************** *** 1861,1867 **** The autocommit-on mode is <productname>PostgreSQL</>'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 ! <filename>psql.rc</filename> or your <filename>.psqlrc</filename> file. </para> </note> --- 1861,1867 ---- The autocommit-on mode is <productname>PostgreSQL</>'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 ! <filename>psqlrc</filename> or your <filename>.psqlrc</filename> file. </para> </note> *************** *** 2491,2499 **** <para> Before starting up, <application>psql</application> attempts to read and execute commands from the the system-wide ! <filename>psql.rc</filename> file and the <filename>$HOME/.psqlrc</filename> file in the user's home ! directory. See <filename><replaceable>PREFIX</>/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 <command>SET</command> commands). --- 2491,2499 ---- <para> Before starting up, <application>psql</application> attempts to read and execute commands from the the system-wide ! <filename>psqlrc</filename> file and the <filename>$HOME/.psqlrc</filename> file in the user's home ! directory. See <filename><replaceable>PREFIX</>/share/psqlrc.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 <command>SET</command> commands). Index: src/bin/psql/Makefile =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/psql/Makefile,v retrieving revision 1.41 diff -c -c -r1.41 Makefile *** src/bin/psql/Makefile 22 Apr 2004 01:53:37 -0000 1.41 --- src/bin/psql/Makefile 22 Apr 2004 14:06:44 -0000 *************** *** 50,56 **** install: all installdirs $(INSTALL_PROGRAM) psql$(X) $(DESTDIR)$(bindir)/psql$(X) ! $(INSTALL_DATA) $(srcdir)/psql.rc.sample $(DESTDIR)$(datadir)/psql.rc.sample installdirs: $(mkinstalldirs) $(DESTDIR)$(bindir) --- 50,56 ---- install: all installdirs $(INSTALL_PROGRAM) psql$(X) $(DESTDIR)$(bindir)/psql$(X) ! $(INSTALL_DATA) $(srcdir)/psqlrc.sample $(DESTDIR)$(datadir)/psqlrc.sample installdirs: $(mkinstalldirs) $(DESTDIR)$(bindir) Index: src/bin/psql/startup.c =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/psql/startup.c,v retrieving revision 1.89 diff -c -c -r1.89 startup.c *** src/bin/psql/startup.c 22 Apr 2004 01:53:37 -0000 1.89 --- src/bin/psql/startup.c 22 Apr 2004 14:06:44 -0000 *************** *** 45,51 **** PsqlSettings pset; #define PSQLRC ".psqlrc" ! #define SYSPSQLRC "psql.rc" /* * Structures to pass information between the option parsing routine --- 45,51 ---- PsqlSettings pset; #define PSQLRC ".psqlrc" ! #define SYSPSQLRC "psqlrc" /* * Structures to pass information between the option parsing routine