From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Scott Goodwin <scott(at)scottg(dot)net>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Patch to psql to allow SEARCH_PATH to be set from env |
Date: | 2004-02-10 15:30:08 |
Message-ID: | 14955.1076427008@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> Do you know that you can go ALTER USER yourselft SET SEARCH_PATH TO
> "'public','core','objects'"; So that will always be your default path?
Another possibility is to issue the SET from a ~/.psqlrc file (I think
that's what it's called, check the man page).
It makes sense to support environment variables for connection
parameters, since those can't be gotten from the database (for obvious
reasons) nor from ~/.psqlrc (which isn't read till after connecting).
But I'm not eager to support environment variables for things that can
be set those ways. There are a heck of a lot of SET variables --- would
we want an env var for each one? (Seen in this light, PGCLIENTENCODING
is a wart, but I suppose we have to keep it for backwards compatibility.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-10 15:55:41 | Re: [PATCHES] Current-stream read for psql's \copy |
Previous Message | Bruce Momjian | 2004-02-10 15:16:14 | Re: [PATCHES] Current-stream read for psql's \copy |