Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Add regression tests for CSV and \., and add

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: momjian(at)postgresql(dot)org, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Add regression tests for CSV and \., and add
Date: 2005-12-28 15:02:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committers
Andrew Dunstan wrote:
> Bruce Momjian said:
> > Log Message:
> > -----------
> > Add regression tests for CSV and \., and add automatic quoting of a
> > single column dump that has a \. value, so the load works properly.  I
> > also added documentation describing this issue.
> >
> This seems unnecessarily elaborate, in code that is already byzantine. I
> think we can safely quote *any* field that has \. regardless of whether or
> not it is a singleton. There's no need to make a single column a special
> case - if it's valid for a singleton it's valid for any, and vice versa.

Only \. as a single column will be interpreted as an end-of-data, so I
want to be accurate in what we do, rather than sloppy.  If we quote any
\. data value, we are going to get questions from people as why _one_
value is quote and the others are not, and we are going to have to
explain that it is quoted in column 4, but in reality it is only it
being alone that needs quoting.  I don't think we want to be
inconsistent because that leads to confusion.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-committers by date

Next:From: Bruce MomjianDate: 2005-12-28 15:07:03
Subject: pgsql: Add COPY CSV test that tests CSV output of \.
Previous:From: Bruce MomjianDate: 2005-12-28 14:38:43
Subject: pgsql: Update COPY CSV \.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group