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