>Von: pgsql-hackers-owner@postgresql.org [pgsql-hackers-owner@postgresql.org]" im Auftrag von "Gilles Darold
[gilles.darold@dalibo.com]
>I was looking at psql 8.3 documention about \pset options and saw that
>there was the following note :
>
> "Note: It is an error to call \pset without any arguments. In the
>future this case might show the current status of all printing options."
>
>I looked backward and forward to find that this note is present in all
>versions since 7.1 up to 9.3, maybe it is time to add this little feature.
>
>I've attached a patch to add the usage of the \pset command without any
>arguments to displays current status of all printing options instead of
>the error message. Here is a sample output:
>
> (postgres@[local]:5494) [postgres] > \pset
> Output format is aligned.
> Border style is 2.
> Expanded display is used automatically.
> Null display is "NULL".
> Field separator is "|".
> Tuples only is off.
> Title is unset.
> Table attributes unset.
> Line style is unicode.
> Pager is used for long output.
> Record separator is <newline>.
> (postgres@[local]:5494) [postgres] >
Hello,
this is a nice additional feature.
As a user (not a hacker), I would prefer to see the real parameter name instead of the "display name".
e.g.
Border style is 2.
=>
border = 2
without this, the user would not know out of the fly which parameter to modify...
best regards,
Marc Mamin
>To avoid redundant code I've added a new method printPsetInfo() so that
>do_pset() and exec_command() will used the same output message, they are
>all in src/bin/psql/command.c. For example:
>
> (postgres@[local]:5494) [postgres] > \pset null 'NULL'
> Null display is "NULL".
> (postgres@[local]:5494) [postgres] >
>
>The patch print all variables information from struct printTableOpt when
>\pset is given without any arguments and also update documentation.
>
>Let me know if there's any additional work to do on this basic patch or
>something that I've omitted.
>
>Best regards,
>
>--
>Gilles Darold
>http://dalibo.com - http://dalibo.org