Enhanced psql in core?

2011/7/9 hubert depesz lubaczewski <depesz@depesz.com>:

hi,
would it be possible to incorporate
http://www.postgres.cz/index.php/Enhanced-psql in core PostgreSQL/psql?

This patch adds lots of nice functionalities, which we could definitely
use.

Some features are very interesting but I I would suggest to split each
in a separate patch proposal.

The \lf is a must have, imo.

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

On Sat, Jul 9, 2011 at 5:29 AM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:

hi,
would it be possible to incorporate
http://www.postgres.cz/index.php/Enhanced-psql in core PostgreSQL/psql?

This patch adds lots of nice functionalities, which we could definitely
use.

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?
i'm not really sure if we can do what the same as your example using
DO but i'm really dubious about the usefullness of that example.

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

On Sat, Jul 9, 2011 at 8:14 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:

On Sat, Jul 9, 2011 at 5:29 AM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:

hi,
would it be possible to incorporate
http://www.postgres.cz/index.php/Enhanced-psql in core PostgreSQL/psql?

This patch adds lots of nice functionalities, which we could definitely
use.

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?
i'm not really sure if we can do what the same as your example using
DO but i'm really dubious about the usefullness of that example.

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

At least it would be useful to have conditional includes...

\if ...
\i something.sql
\endif

2011/7/10 Jaime Casanova <jaime@2ndquadrant.com>:

On Sat, Jul 9, 2011 at 5:29 AM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:

hi,
would it be possible to incorporate
http://www.postgres.cz/index.php/Enhanced-psql in core PostgreSQL/psql?

This patch adds lots of nice functionalities, which we could definitely
use.

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?
i'm not really sure if we can do what the same as your example using
DO but i'm really dubious about the usefullness of that example.

DO has same limits like functions - you cannot to switch database, you
cannot to store data to psql's session variables, you cannot do
"include file"

Regards

Pavel

Hello

2011/7/9 Cédric Villemain <cedric.villemain.debian@gmail.com>:

2011/7/9 hubert depesz lubaczewski <depesz@depesz.com>:

hi,
would it be possible to incorporate
http://www.postgres.cz/index.php/Enhanced-psql in core PostgreSQL/psql?

This patch adds lots of nice functionalities, which we could definitely
use.

Some features are very interesting but I I would suggest to split each
in a separate patch proposal.

The \lf  is a must have, imo.

This patch is relative old - a few features are in core now - UTF8
decoration, and listing function source code,

see \sf command in 9.1

I agree, so these features should be split. This old patch was a
"features preview"

there is areas:

* custom line's formats
* enhanced formatting - multiline headers, wrapping in white chars
* basic scripting - \execute function
* enhanced scripting \if \forc statements
* macros

Regards

Pavel Stehule

2011/7/10 Pavel Stehule <pavel.stehule@gmail.com>:

2011/7/10 Jaime Casanova <jaime@2ndquadrant.com>:

On Sat, Jul 9, 2011 at 5:29 AM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:

hi,
would it be possible to incorporate
http://www.postgres.cz/index.php/Enhanced-psql in core PostgreSQL/psql?

This patch adds lots of nice functionalities, which we could definitely
use.

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?
i'm not really sure if we can do what the same as your example using
DO but i'm really dubious about the usefullness of that example.

DO has same limits like functions - you cannot to switch database, you
cannot to store data to psql's session variables, you cannot do
"include file"

note - a output from DO statement is limited to RAISE statement - you
can't send back a SELECT's result

Regards

Pavel

Pavel Stehule <pavel.stehule@gmail.com> writes:

2011/7/10 Jaime Casanova <jaime@2ndquadrant.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.

regards, tom lane

2011/7/10 Tom Lane <tgl@sss.pgh.pa.us>:

Pavel Stehule <pavel.stehule@gmail.com> writes:

2011/7/10 Jaime Casanova <jaime@2ndquadrant.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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

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.

I don't think we're ever going to have DO able to do cross-database
things, or top-level transaction control, etc. Perhaps, some day, we'll
have a way to do that kind of thing in the back-end (I certainly hope
so, and Berkus had posted a lot of good thoughts about that not too long
ago), but even so, I think it'd be great to have some real scripting
capability in psql and I'm all for fixing the variable handling w/
a ":{var}" capability..

Thanks,

Stephen