Re: 2018-03 Commitfest Summary (Andres #1)

2018-03-04 8:29 GMT+01:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:

> On 4 March 2018 at 14:58, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>
>>
>> 2018-03-04 3:09 GMT+01:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
>>
>>> On 3 March 2018 at 17:56, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>>>
>>>>
>>>> The (trivial) big picture is to allow client-side expressions in psql
>>>> (which as a \if:-) by reusing pgbench expression engine, so that one could
>>>> write things like
>>>>
>>>> \let i :j + 12 * :k
>>>>
>>>> or
>>>>
>>>> \if :VERSION_NUM < 140000
>>>>
>>>>
>>> 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.
>>>
>>
>> I am primary a psql user, so I'll talk about psql. I don't need there
>> more functionality, than has C macros. Not more. So \if :VERSION_NUM < x is
>> good enough. && || operators are nice to have
>>
>> For this I don't to join any VM. It is overkill. What scripting
>> functionality we can do in psql now, and probably in long future
>>
>> a) setting prompt
>> b) some deployment - version checks
>> c) implementation of some simple regress scenarios
>>
>> Can be different if we start new rich TUI client based on ncurses, new
>> features - but it is different story.
>>
>> More - implementation of simple expression evaluation in psql doesn't
>> break later integration of some VM. Maybe it prepare a way for it.
>>
>> I can imagine the psql command \lua anylua expression, with possibility
>> to call any lua function with possibility to iterate over SQL result, show
>> any result, and read, write from psql variables - prefer Lua against
>> JavaScript, but same can be done there too.
>>
>> But this not against to this patch. This patch is not too big, too
>> complex, too hard to maintain - and some simple today issues can be done
>> simple
>>
>>
> Fine by me so long as it remains a manageable scope, rather than
> incrementally turning into some horror scripting language.
>

It is Postgres development limited by commitfest cycles - step by step. I
can imagine to grow this scripting possibilities - but programming any
non-trivial task in \xxx commands is everything, but not nice and friendly.
This is natural and practical limit. So the scope is limited to expression
evaluation. Nothing more. Maybe, if there will be a agreement and spirit,
we can talk about some new concepts for psql, pgbench to allow some more
customization or some modernization. Personally, I am almost happy with
psql, when I wrote pspg :). We can get some inspiration from pgcli
https://github.com/dbcli/pgcli. These people does good work - but due
python it is slower in visualisation. After this commitfest I'll start
discussion, what is missing in psql.

Maybe integration of some VM can reduce lot of code inside psql and can
help with better autocomplete implementation - but it is pretty long story,
and it means direct dependecy on selected VM.

Regards

Pavel

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

>