Re: [PATCHES] allow CSV quote in NULL

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] allow CSV quote in NULL
Date: 2008-03-11 22:47:54
Message-ID: 200803112247.m2BMlsO14982@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Added to TODO for COPY:

o Allow COPY in CSV mode to control whether "" is treated as NULL

http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php

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

Andrew Dunstan wrote:
>
> [redirecting to -hackers]
>
> Stephen Frost wrote:
> > * Gregory Stark (stark(at)enterprisedb(dot)com) wrote:
> >
> >> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >>
> >>
> >>> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> >>>
> >>>> Please find attached a minor patch to remove the constraints that a
> >>>> user can't include the delimiter or quote characters in a 'NULL AS'
> >>>> string when importing CSV files.
> >>>>
> >>> This can't really be sane can it?
> >>>
> >
>
> Not very, no :-)
> >
> >> The alternative would be interpreting NULL strings after dequoting but that
> >> would leave no way to include the NULL string literally. This solution means
> >> there's no way to include it (if it needs quoting) but only when you specify
> >> it this way.
> >>
> >
> > Yeah, interpreting NULLs after dequoting means you've lost the
> > information about if it's quoted or not, or you have to add some funky
> > syntax to say "if it's quoted, do it differently...", which is no good,
> > imv.
> >
> > What the patch does basically is say "give us the exact string that
> > shows up between the unquoted delimiters that you want to be treated
> > as a NULL." This removes the complexity of the question about quoting,
> > unquoting, whatever, and makes it a very clear-cut, straight-forward
> > solution with no impact on existing users, imv.
> >
> >
> >
>
> This looks too clever by half, to me. Someone facing the problem you are
> facing would have to dig quite deep to find the solution you're promoting.
>
> A much better way IMNSHO would be to add an extra FORCE switch. On
> input, FORCE NOT NULL says to treat an unquoted null as the literal
> value rather than as a null field for the columns named. The reverse
> would be to tell it to treat a quoted null as null rather than as the
> literal value, for the named columns. Perhaps that should just be "FORCE
> NULL columnlist". It would be more explicit and at the same time would
> only apply to the named columns, rather than discarding totally the
> ability to distinguish between null and not null values.
>
> This should probably be discussed on -hackers, anyway.
>
>
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2008-03-11 22:57:44 Re: COPY issue(gsoc project)
Previous Message Bruce Momjian 2008-03-11 22:31:21 Re: plpgsql and qualified variable names

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-03-11 23:21:04 Proposed patch for LISTEN/NOTIFY race condition
Previous Message Bruce Momjian 2008-03-11 21:25:13 Re: SPI-header-files safe for C++-compiler