| From: | David Kerr <dmk(at)mr-paradox(dot)net> |
|---|---|
| To: | David Johnston <polobo(at)yahoo(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: SQL Path in psql |
| Date: | 2013-09-06 17:58:05 |
| Message-ID: | 20130906175805.GB42707@mr-paradox.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Sep 06, 2013 at 10:45:26AM -0700, David Johnston wrote:
- lup wrote
- >>
- >>
- > I wonder if this would at least get the full path on-screen for a c/p
- > \! for d in $SQLPATH; do find $d -name
- > <script-filename>
- > ; done
- >
- > That said, I would down-vote this suggestion. I tend to put sql files
- > in amongst my various project dirs and maintaining the envvar isn't
- > worth it.
- >
- > Anything I re-use I make into a function.
-
- Usually a down-vote there is something that can go wrong if the feature is
- implemented. Simply not personally having a use for said feature normally
- results in a "+0" vote or something similar.
-
- The big issue with environment variables is their ability to have resolution
- conflicts. I think the general idea has merit though setting symbolic-links
- (in Linux variants at least) can get you some of the way there in a less
- error-prone (but more verbose) way.
-
- Ultimately feature requests get made to here then end up on the ToDo listing
- if the idea has traction.
-
- David J.
I suspect this feature makes more sense on a windows platform. On linux where we can
go psql -f ${SQLPATH}/file.sql . it becomes less pressing. Even Oracle
on unix/linux where you can go sqlplus <<EOD @${SQLPATH}/file.sql EOD. makes
it less a requirement.
on the other hand, does seems like a pretty easy thing to implement.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Miles Pomeroy | 2013-09-06 19:14:15 | Re: SQL Path in psql |
| Previous Message | David Johnston | 2013-09-06 17:45:26 | Re: SQL Path in psql |