Re: 2018-03 Commitfest Summary (Andres #1) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: 2018-03 Commitfest Summary (Andres #1)
Date
Msg-id alpine.DEB.2.20.1803041104190.12500@lancre
Whole thread Raw
In response to Re: 2018-03 Commitfest Summary (Andres #1)  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Hello Craig,

> I still haven't really grasped why this isn't done by embedding a
> client-side scripting language interpreter, giving us vastly greater
> capabilities with only the maintenance of the glue instead of writing our
> own ad-hoc scripting tool. Something confine-able like JavaScript or Lua.

ISTM that what you are asking for cannot work well: Pg needs a client the 
primary language of which is SQL, so that:

   calvin> SELECT * FROM Stuff;

Does what you expect.

How would you mix/embedded another language with that? The answer is not 
obvious to me because you need some lexical convention to switch between 
SQL and the "other" language. PHP-looking solution or putting all SQL in 
strings would not be that great in interactive mode.

Moreover, I do not think that a full language (including loops) is 
desirable for interactive scripting and simple database creations. The 
needed level is more like cpp, i.e. not really a "full" language.

Also, which language should it be? I've been practicing perl, tcl, python, 
bash... do I want to learn lua as well?

So ISTM that the current solution is the reasonable one: limited 
SQL-language tools (psql & pgbench) for basic and interactive operations, 
and if you really need scripting you can always write a script in your 
favorite language which is interfaced with SQL through some API.

The limit between what can be done with the client tool and with scripting 
is a fuzzy one.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Ants Aasma
Date:
Subject: Re: All Taxi Services need Index Clustered Heap Append
Next
From: David Rowley
Date:
Subject: Re: All Taxi Services need Index Clustered Heap Append