From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgbench - add \if support |
Date: | 2018-01-22 05:20:23 |
Message-ID: | alpine.DEB.2.20.1801220603330.6320@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Helo Craig,
> I'm a smidge worried about this. It seems like psql is growing a
> scripting language.
The patch is about aligning pgbench with psql, which already has \if.
> Do we want to go our own way with a kind of organically grown
> scripting system? Or should we be looking at embedding client-side
> scripting in a more structured, formal way instead? Embed a lua interpreter
> or something?
My 0.02€ is that the point is to deal with useful/needed simple client
capabilities while integrating gracefully with bare server-side executed
SQL.
As for useful client-side capabilities, for both psql & pgbench ISTM that
it is more in line with a limited cpp-like thing: include, expressions,
variables, conditions... maybe minimal error handling. No loop.
As for a language interpreter, it would raise the question of which
language (lua, tcl, python, perl, VB, sh, R, ...) and the graceful (upward
compatible) integration of any such language: eg how do have pieces of
bare SQL and any other existing language would require some scanning
conventions that do not exist.
psql & pgbench already have ":x" variables. psql has the ability to set
variable from SQL (\gset), and pgbench could do limited expressions to set
these variables with (\set), which have been extended to be more complete
, and there was use cases which motivate an (\if).
ISTM enough to align both tools for reasonnably simple use cases that
could arise when running a basic SQL script of bench. If you have
something really complicated, then full fledge programming is the answer,
which cannot be bare-SQL compatible.
So the answer is that it is okay to aim at "limited" scripting because it
covers useful use cases.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2018-01-22 05:30:56 | Re: Doc tweak for huge_pages? |
Previous Message | Peter Geoghegan | 2018-01-22 05:06:26 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |