Thread: 8.2.0 psql \df+ output mangled a bit relative to 8.1.4 ...

With a database loaded into 8.2.0 from a dump from an 8.1.4 server,
"\df+  foo()", where foo()'s body has embedded tabs shows up with
those tabs escaped, whereas under 8.1.4 they were emitted verbatim:

Is there a trick to getting old behaviour back? It seems to happen
regardless of client_encoding setting (either SQL_ASCII or latin1).
Thanks!


8.2.0:
social=# \df+ housing.update_terse_listing_by_unit()

                       List of functions
Schema  |             Name             | Result data type | Argument
data types | Owner  | Language |
Source code                                      | Description
---------+------------------------------+------------------
+---------------------+--------+----------
+-----------------------------------------------------------------------
----------------+-------------
housing | update_terse_listing_by_unit | "trigger"
|                     | social | plpgsql
|
                 |

                               : BEGIN

                               : \x09if TG_OP = 'UPDATE' then

                               : \x09\x09update housing.terse_listing
set last_modified = now() where id = NEW.id;

                               : \x09else

                               : \x09\x09insert into
housing.terse_listing (id, last_modified) values (NEW.id, now());

                               : \x09end if;

                               : \x09return null;

                               : END;

                               :
(1 row)


8.1.4:

social=# \df+ housing.update_terse_listing_by_unit()


                     List of functions
Schema  |             Name             | Result data type | Argument
data types | Owner  | Language
|
                                     Source
code
                                        | Description
---------+------------------------------+------------------
+---------------------+--------+----------
+-----------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
----------+-------------
housing | update_terse_listing_by_unit | "trigger"
|                     | social | plpgsql  |
BEGIN
         if TG_OP = 'UPDATE' then
                 update housing.terse_listing set last_modified = now
() where id = NEW.id;
         else
                 insert into housing.terse_listing (id,
last_modified) values (NEW.id, now());
         end if;
         return null;
END;
|



----
James Robinson
Socialserve.com

On Thu, Dec 21, 2006 at 10:25:02AM -0500, James Robinson wrote:
> With a database loaded into 8.2.0 from a dump from an 8.1.4 server,
> "\df+  foo()", where foo()'s body has embedded tabs shows up with
> those tabs escaped, whereas under 8.1.4 they were emitted verbatim:

It's part of the aligned output patch. As you can see, it preserves the
alignment of the columns, whereas 8.1 did not.

> Is there a trick to getting old behaviour back? It seems to happen
> regardless of client_encoding setting (either SQL_ASCII or latin1).
> Thanks!

Well, in unaligned mode it's still the old way. There was some
discussion at the time about whether tabs should be converted to spaces
on output, but I don't think that got anywhere...

It's a psql only thing BTW, other programs will not see it.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Many thanks!

\a
before \df+ does the trick.

James

On Dec 21, 2006, at 10:31 AM, Martijn van Oosterhout wrote:
>
> Well, in unaligned mode it's still the old way. There was some
> discussion at the time about whether tabs should be converted to
> spaces
> on output, but I don't think that got anywhere...
>
> It's a psql only thing BTW, other programs will not see it.
>
> Have a nice day,
> --
> Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/
> kleptog/
>> From each according to his ability. To each according to his
>> ability to litigate.

----
James Robinson
Socialserve.com