Обсуждение: SQL Path in psql
I come from an Oracle background and I am fairly new to Postgres. Oracle's command line utility (SQL*Plus) uses an environment variable called SQLPATH to search the given directories for SQL scripts that the user calls to execute using a method similar to the \i meta-command in psql. This allows users to put SQL scripts in various directories and execute them no matter which directory is there current working directory in psql.
Is there a similar environment variable that can be used with psql, or another way to mimic this behavior?
Thanks,
Bobby
Bobby Dewitt wrote > I come from an Oracle background and I am fairly new to Postgres. > Oracle's command line utility (SQL*Plus) uses an environment variable > called SQLPATH to search the given directories for SQL scripts that the > user calls to execute using a method similar to the \i meta-command in > psql. This allows users to put SQL scripts in various directories and > execute them no matter which directory is there current working directory > in psql. > > Is there a similar environment variable that can be used with psql, or > another way to mimic this behavior? I'm in the same boat as Bobby. Any feature like this exist? If not, how would it be requested? -- View this message in context: http://postgresql.1045698.n5.nabble.com/SQL-Path-in-psql-tp4413658p5769925.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On 09/06/2013 11:05 AM, miles wrote: > Bobby Dewitt wrote >> I come from an Oracle background and I am fairly new to Postgres. >> Oracle's command line utility (SQL*Plus) uses an environment variable >> called SQLPATH to search the given directories for SQL scripts that the >> user calls to execute using a method similar to the \i meta-command in >> psql. This allows users to put SQL scripts in various directories and >> execute them no matter which directory is there current working directory >> in psql. >> >> Is there a similar environment variable that can be used with psql, or >> another way to mimic this behavior? > I'm in the same boat as Bobby. Any feature like this exist? If not, how > would it be requested? > > > > -- > View this message in context: http://postgresql.1045698.n5.nabble.com/SQL-Path-in-psql-tp4413658p5769925.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > 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.
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. -- View this message in context: http://postgresql.1045698.n5.nabble.com/SQL-Path-in-psql-tp4413658p5769929.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
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.
In my opinion, the use of such a feature is to make simple, commonly
used scripts available from wherever you start up psql and no matter
what database you are connecting to. On Oracle/SQL*Plus I have used
this feature to create simple scripts that replicate informational
backslash commands in psql. If there was someway to define your own
backslash commands in the .psqlrc, that would be even better.
Miles.
On Fri, Sep 6, 2013 at 11:58 AM, David Kerr <dmk@mr-paradox.net> wrote:
> 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.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
On Fri, Sep 6, 2013 at 1:58 PM, David Kerr <dmk@mr-paradox.net> wrote:
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.
I don't see why you couldn't do the same thing in command prompt on Windows:
SET PGSQLPATH=C:\somedir
psql -f %PGSQLPATH%\file.sql
Naturally, you could configure a permanent environment variable instead of using SET.