Brook,
I have a lot of shell scripts that run as cron jobs and have considered
this option. However, if you look at it carefully, SQL is totally
different from say perl, php, bash, etc. for scripts which execute from
the shell. Tom is right, it is much more valuable and supportable to
call psql from within a shell script than add the functionality to psql
itself.
-Jonah
[EMAIL PROTECTED] wrote:
Tom Lane writes:
> Given that # is not a comment introducer in SQL, I would consider
> it a bug if it did.
I understand that # is not a comment introducer in SQL. I am
wondering if it would be sensible to introduce an exception for the
first line of a file. To prevent problems the behavior should be
controlled by a command line option (-i?) so that it would never have
this behavior unless explicitly asked for.
I guess you see no value in this and instead would solve the issue
with a separate interpreter that has this property? Note that a shell
script cannot be an interpreter for execve(2); thus, this would
require another binary executable.
My own feeling was that psql could be easily taught to have this
behavior in a way that would not interfer with any existing
applications. I at least can see benefits to having that capability,
but perhaps others do not. For example, some of my large database
applications are built by running a large collection of scripts (some
are shell scripts, some sql, etc.), each of which is responsible for a
portion of the task. It would be very handy to execute each member of
the collection in a uniform manner, i.e., as a direct execution with
execve(2) figuring out which interpreter to use on a script-by-script
basis. Currently, that is not possible, but it could be with a small
modification to psql or the addition of a completely new interpreter.
Thanks for the comments.
Cheers,
Brook
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
