Re: pgbench - add \if support
От | Fabien COELHO |
---|---|
Тема | Re: pgbench - add \if support |
Дата | |
Msg-id | alpine.DEB.2.20.1801220603330.6320@lancre обсуждение исходный текст |
Ответ на | Re: pgbench - add \if support (Craig Ringer <craig@2ndquadrant.com>) |
Список | 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.
В списке pgsql-hackers по дате отправления: