Re: pgbench - add \if support

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.

In response to

Browse pgsql-hackers by date

  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)