Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > Actually, no. If I cut'n paste the number from psql to > > > cat > foo > > > <shift> <insert> > > > then only 4096 chars are copied. (Amusingly, I can't add a newline to > > > ^D and close the file. I must delete one char to do that.) > > > > Hmm, cut buffer limitation in X or someplace? I definitely get the > > right number of characters into the file written with \g, and what looks > > like a reasonable number of screensful of plain psql output. If Bruce > > is seeing the right number of dashes and the wrong number of data > > characters in his \g output then *something* is pretty weird there. > > Well, I just tried the \g test and it is correct (12675 digits or so).
I just tested from a standalone backend: backend> select pow(10::numeric, 131071) + 1 and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it must be something in the backend. -- 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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match