In message <[EMAIL PROTECTED]>, Tom Lane avows:
%--- Begin Cite ---%
> James Tanis <[EMAIL PROTECTED]> 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.


>                       regards, tom lane
%--- End Cite ---%      

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to