Thread: Bug in psql's "-R" option?

Bug in psql's "-R" option?

From
Murthy Kambhampaty
Date:
There seems to be a bug in psql's -R option (and the -P recordsep= )
version. I find that whereas the following succeeds:

/usr/local/pgsql/bin/psql -U xxxx -d xxxx -h xxxx \
    -P format=unaligned -P fieldsep='\t' -P tuples_only \
    -c "select * from tab where yoo='hoo'" | /usr/local/pgsql/bin/psql
-U xxxx -d xxxx -h xxxx \
    -c "copy bar from stdin"

adding -R '\n' or -P recordsep='\n' or -P recordsep=newline all give an
error that the last field's data is too long for that field's format.
Presently, this seems a bogus option, since the COPY command cannot handle
any record separator except a newline, but the documentation for the "copy
from" command states that '\n' will be parsed as a newline, so this seems a
bug.

Re: Bug in psql's "-R" option?

From
Bruce Momjian
Date:
psql -R controls the record separator for query output, not COPY.

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

Murthy Kambhampaty wrote:
> There seems to be a bug in psql's -R option (and the -P recordsep= )
> version. I find that whereas the following succeeds:
>
> /usr/local/pgsql/bin/psql -U xxxx -d xxxx -h xxxx \
>     -P format=unaligned -P fieldsep='\t' -P tuples_only \
>     -c "select * from tab where yoo='hoo'" | /usr/local/pgsql/bin/psql
> -U xxxx -d xxxx -h xxxx \
>     -c "copy bar from stdin"
>
> adding -R '\n' or -P recordsep='\n' or -P recordsep=newline all give an
> error that the last field's data is too long for that field's format.
> Presently, this seems a bogus option, since the COPY command cannot handle
> any record separator except a newline, but the documentation for the "copy
> from" command states that '\n' will be parsed as a newline, so this seems a
> bug.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
  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

Re: Bug in psql's "-R" option?

From
Murthy Kambhampaty
Date:
OK, sorry for the muddle-headed post (I realized my error as I walked away
from my desk ...).

The bug seems to be in the copy from parsing, which does not follow the
documentation as I related in my original message.

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Tuesday, November 05, 2002 14:21
To: Murthy Kambhampaty
Cc: 'pgsql-admin@postgresql.org'
Subject: Re: [ADMIN] Bug in psql's "-R" option?



psql -R controls the record separator for query output, not COPY.

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

Murthy Kambhampaty wrote:
> There seems to be a bug in psql's -R option (and the -P recordsep= )
> version. I find that whereas the following succeeds:
>
> /usr/local/pgsql/bin/psql -U xxxx -d xxxx -h xxxx \
>     -P format=unaligned -P fieldsep='\t' -P tuples_only \
>     -c "select * from tab where yoo='hoo'" | /usr/local/pgsql/bin/psql
> -U xxxx -d xxxx -h xxxx \
>     -c "copy bar from stdin"
>
> adding -R '\n' or -P recordsep='\n' or -P recordsep=newline all give an
> error that the last field's data is too long for that field's format.
> Presently, this seems a bogus option, since the COPY command cannot handle
> any record separator except a newline, but the documentation for the "copy
> from" command states that '\n' will be parsed as a newline, so this seems
a
> bug.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
  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