Re: TODO item -- Improve psql's handling of multi-line - Mailing list pgsql-patches

Modified to use a macro with value 0x01.  Applied.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Sergey E. Koposov wrote:
> > On Sat, 11 Feb 2006, Tom Lane wrote:
> >
> > > "Sergey E. Koposov" <math@sai.msu.ru> writes:
> > > > But concerning to your zero byte change, it currently just broke
> > > > everything (as I thought, and that's why I didn't implemented it). The
> > > > problem with using zero byte is that it breaks all the readline functions
> > > > read_history and write_history. Those functions deal with usual C
> > > > strings, so putting zero byte inside them will just truncate everything.
> > > > (that's exactly what occur with the psql from CVS).
> > >
> > > If CVS tip is actually broken, we'd better revert this patch and
> > > rethink the approach.
> > >
> > > > So, I don't know. There are two alternatives. One is to use 0x01 byte
> > > > instead: (at least I don't really agree with Tom's comments about possible
> > > > problems with using 0x01 with some exotic encodings)
> > >
> > > Just because you don't use far eastern encodings doesn't mean there's
> > > not a large contingent who do.
> > >
> >
> > I have said the phrase that I don't agree only after at least some
> > checking of the encodings:
> > 1) First I greped the map files
> > pgsql/src/backend/utils/mb/Unicode/*.map and there is no 0x01 byte in any
> > encoding.
> > 2) UCS, UTF don't use 0x01 inside the multibyte chars.
> > 3) I looked on the most problematic encodings like BIG5, JIS, SJIS,
> > ISO-2022-JP
> > http://en.wikipedia.org/wiki/Big5
> > http://lfw.org/text/jp.html
> > and they certainly don't use the 0x01 byte.
> > So myself I'm rather convinced that the 0x01 byte is safe. Probably that's
> > not true, but I have no evidence for that.
> >
>
> OK, seems you did your homework.  I will modify the code to use 0x01
> unless someone can find an encoding we support that uses 0x01.  I will
> use a macro for 0x01 so it is clearer.
>
> > > I don't understand why any of these shenanigans are needed.  If \e is
> > > able to stick a multiline entry into the history, why can't the other
> > > code do it?
> > >
> >
> > The problem is in saving those multiline queries to the disk and
> > loading them again as multiline on next psql session and not with
> > putting the queries into the history for one psql session (that thing
> > works with that patch perfectly fine).
>
> Right, I tested that.  Even your patch, if someone does \e and edits a
> query, and then exits psql and restarts it, the query is in lines,
> right, so \e really doesn't work even without your patch.
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: src/bin/psql/input.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/input.c,v
retrieving revision 1.47
diff -c -c -r1.47 input.c
*** src/bin/psql/input.c    11 Feb 2006 21:55:35 -0000    1.47
--- src/bin/psql/input.c    12 Feb 2006 05:21:55 -0000
***************
*** 26,31 ****
--- 26,40 ----
  static bool useHistory;
  char       *psql_history;

+ /*
+  *    Preserve newlines in saved queries by mapping '\n' to NL_IN_HISTORY
+  *
+  *    It is assumed NL_IN_HISTORY will never be entered by the user
+  *    nor appear inside a multi-byte string.  0x00 is not properly
+  *    handled by the readline routines so it can not be used
+  *    for this purpose.
+  */
+ #define NL_IN_HISTORY    0x01

  enum histcontrol
  {
***************
*** 213,219 ****
           cur_hist; cur_hist = next_history())
          for (cur_ptr = cur_hist->line; *cur_ptr; cur_ptr++)
              if (*cur_ptr == '\n')
!                 *cur_ptr = '\0';
  }

  static void decode_history()
--- 222,228 ----
           cur_hist; cur_hist = next_history())
          for (cur_ptr = cur_hist->line; *cur_ptr; cur_ptr++)
              if (*cur_ptr == '\n')
!                 *cur_ptr = NL_IN_HISTORY;
  }

  static void decode_history()
***************
*** 224,230 ****
      for (history_set_pos(0), cur_hist = current_history();
           cur_hist; cur_hist = next_history())
          for (cur_ptr = cur_hist->line; *cur_ptr; cur_ptr++)
!             if (*cur_ptr == '\0')
                  *cur_ptr = '\n';
  }

--- 233,239 ----
      for (history_set_pos(0), cur_hist = current_history();
           cur_hist; cur_hist = next_history())
          for (cur_ptr = cur_hist->line; *cur_ptr; cur_ptr++)
!             if (*cur_ptr == NL_IN_HISTORY)
                  *cur_ptr = '\n';
  }