Cliff Nieuwenhuis wrote: > On Tuesday 11 March 2008 11:41:35 Tom Lane wrote: > > Cliff Nieuwenhuis <[EMAIL PROTECTED]> writes: > > > I'm not sure how to ask this question. I have written a function, and > > > with PostgreSQL 8.0.13 I can do a "\df+" and see something like this > > > under Source Code: > > > DECLARE > > > result text; > > > ... > > > > > > If I create the same function on my computer running PostgreSQL 8.3.0 and > > > try the \df+ then the Source Code shows: > > > > > > \x09DECLARE > > > \x09\x09result text; > > > ... > > > > That's not an encoding problem, that's an intentional behavioral change > > in the way that psql formats strings for display. > > > > I guess it's a bit annoying if you were hoping that tabs would be useful > > for pretty-printing purposes. Should we reconsider what's done with a > > tab in mbprint.c? > > > > regards, tom lane > > My vote would be to go back to the old way, or at least have that as an > option > of some sort. I use command-line psql all the time -- to me, psql offers the > same advantages as using a command-line interface for other work. I find the > extra characters really get in the way.
Yes, I think our psql display of tabs needs improving too. Our current behavior is to output tab as 0x09: test=> SELECT E'\011'; ?column? ---------- \x09 (1 row) test=> CREATE FUNCTION xx() RETURNS text AS E' test'> SELECT ''a''::text test'> WHERE 1 = 1' test-> LANGUAGE SQL; CREATE FUNCTION test=> SELECT prosrc FROM pg_proc WHERE proname = 'xx'; prosrc --------------------- SELECT\x09'a'::text WHERE\x091 = 1 (1 row) test=> \x Expanded display is on. test=> \df+ xx List of functions -[ RECORD 1 ]-------+-------------------- Schema | public Name | xx Result data type | text Argument data types | Volatility | volatile Owner | postgres Language | sql Source code | : SELECT\x09'a'::text : WHERE\x091 = 1 Description | I have implemented the following patch which outputs tab as a tab. It also assumes a tab has a width of 4, which is its average width: test=> SELECT E'\011'; ?column? ---------- (1 row) test=> SELECT prosrc FROM pg_proc WHERE proname = 'xx'; prosrc --------------------- SELECT 'a'::text WHERE 1 = 1 (1 row) test=> \x Expanded display is on. test=> \df+ xx List of functions -[ RECORD 1 ]-------+-------------------- Schema | public Name | xx Result data type | text Argument data types | Volatility | volatile Owner | postgres Language | sql Source code | : SELECT 'a'::text : WHERE 1 = 1 Description | The only downside I see for this patch is that we are never sure of the display width of tab because we don't know what tab stop we are at. With '\x09' we knew exactly how wide it was. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Index: src/bin/psql/mbprint.c =================================================================== RCS file: /cvsroot/pgsql/src/bin/psql/mbprint.c,v retrieving revision 1.30 diff -c -c -r1.30 mbprint.c *** src/bin/psql/mbprint.c 16 Apr 2008 18:18:00 -0000 1.30 --- src/bin/psql/mbprint.c 7 May 2008 15:18:25 -0000 *************** *** 315,320 **** --- 315,330 ---- linewidth += 2; ptr += 2; } + else if (*pwcs == '\t') /* Tab */ + { + strcpy((char *) ptr, "\t"); + /* + * We don't know what tab stop we are on, so assuming 8-space + * tabs, the average width of a tab is 4. + */ + linewidth += 4; + ptr += 1; + } else if (w < 0) /* Other control char */ { sprintf((char *) ptr, "\\x%02X", *pwcs);
-- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches