Re: PSQLRC environment variable.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PSQLRC environment variable.
Дата
Msg-id 2319.1078893158@sss.pgh.pa.us
обсуждение исходный текст
Ответ на PSQLRC environment variable.  (James Tanis <jtt@sysd.com>)
Ответы Re: PSQLRC environment variable.  (James Tanis <jtt@sysd.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: PSQLRC environment variable.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PSQLRC environment variable.