Re: PSQLRC environment variable. - Mailing list pgsql-patches

From Tom Lane
Subject Re: PSQLRC environment variable.
Date
Msg-id 2319.1078893158@sss.pgh.pa.us
Whole thread Raw
In response to PSQLRC environment variable.  (James Tanis <jtt@sysd.com>)
Responses Re: PSQLRC environment variable.  (James Tanis <jtt@sysd.com>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PSQLRC environment variable.
Next
From: Tom Lane
Date:
Subject: Re: PSQLRC environment variable.