Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group