Re: psql as an execve(2) interpreter

From: "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>
To: brook(at)biology(dot)nmsu(dot)edu
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, brook(at)nmsu(dot)edu
Subject: Re: psql as an execve(2) interpreter
Date: 2005-07-28 17:14:48
Message-ID: 42E91288.7080307@tvi.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

brook(at)biology(dot)nmsu(dot)edu 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
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Swan 2005-07-28 17:50:05 Re: Some new list.c primitives
Previous Message Alvaro Herrera 2005-07-28 15:44:56 Re: [COMMITTERS] pgsql: Basic documentation for ROLEs.