Re: psql as an execve(2) interpreter

Поиск
Список
Период
Сортировка
От
Тема Re: psql as an execve(2) interpreter
Дата
Msg-id 17127.6405.365890.121201@trillium.aquilegia.com
обсуждение исходный текст
Ответ на Re: psql as an execve(2) interpreter  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: psql as an execve(2) interpreter  ("Jonah H. Harris" <jharris@tvi.edu>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RESULT_OID Bug
Следующее
От: Michael Fuhr
Дата:
Сообщение: Re: RESULT_OID Bug