Re: Enhanced psql in core?

2011/7/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>> 2011/7/10 Jaime Casanova <jaime(at)2ndquadrant(dot)com>:
>>>> big part of this seems to be (based on the examples on the page,
>>>> haven't read the patch) scripting functionality but now that we have
>>>> DO, is really a need for that?
>
>> note - a output from DO statement is limited to RAISE statement - you
>> can't send back a SELECT's result
>
> You can't *today*.  But it's a very good question whether it wouldn't
> make more sense to solve these problems by extending DO rather than
> adding things into psql.  Functionality in DO will be available to
> non-psql clients.
>

It should be nice, and I like it - but I think, so some request for
psql enhancing will be valid still. As minimum I see a two features
(maybe three):

a) propagation of some value from server to psql session variables and
to system variables
b) conditional include, conditional processing
c) some form of "alias" like bash

These features should not be a complex. More complex scripting
features should be implemented in "noniteractive" fork of psql - this
is one form of possible solution - or not - I really don't need a new
language.

As minimum for more enhanced using of DO statement is possibility of a
access to psql's session variables, and possibility to return table
(tables) as result. I am not for introduction of new scripting
language like pgscript does, just thinking so some basic features to
psql should be nice - because psql has nice result formatting
features, and has good integration to host environment.

One idea - we can use a NOTIFICATION mechanism for getting a some psql
(or any client) session variable(s). This doesn't need a
parametrisation support for NOT SQL statement.

\set hellovar 'Hello'
DO $$
DECLARE vars text[];
BEGIN
vars := get_client_vars('hellovar');
vars[1] := vars[1] || ', world';
set_host_var('hellovar', vars[1]);
RAISE NOTICE '%', vars[1];
...

I agree with you, so there are no reason for introduction of new
language, but I don't think so DO is final solution and we can
continue without some psql enhancing.

Regards

Pavel

>                        regards, tom lane
>