From: | <brook(at)biology(dot)nmsu(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | brook(at)biology(dot)nmsu(dot)edu, pgsql-hackers(at)postgresql(dot)org, brook(at)nmsu(dot)edu |
Subject: | Re: psql as an execve(2) interpreter |
Date: | 2005-07-27 05:17:57 |
Message-ID: | 17127.6405.365890.121201@trillium.aquilegia.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2005-07-27 05:33:25 | Re: ENUM type |
Previous Message | Tom Lane | 2005-07-27 04:56:15 | Re: RESULT_OID Bug |