Re: Patch: FORCE_NULL option for copy COPY in CSV mode

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: FORCE_NULL option for copy COPY in CSV mode
Date: 2013-10-08 03:34:25
Message-ID: CAA4eK1+6sGsk+YGJgFENC-g5OOMnt3-2UZSLGJ3iqcyWwgxQdA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 10/07/2013 03:06 PM, Robert Haas wrote:
>>
>>
>>> Also if your use case is to treat empty strings as NULL (as per above
>>> documentation), can't it be handled with "WITH NULL AS" option.
>>> For example, something like:
>>>
>>> postgres=# COPY testnull FROM stdin with CSV NULL AS E'';
>>> Enter data to be copied followed by a newline.
>>> End with a backslash and a period on a line by itself.
>>>>>
>>>>> 50,
>>>>> \.
>>>
>>> postgres=# select * from testnull;
>>> a | b
>>> ----+------
>>> 50 | NULL
>>> (1 row)
>>
>> Good point. If this patch is just implementing something that can
>> already be done with another syntax, we don't need it.
>>
>
>
> Isn't the point of this option to allow a *quoted* empty string to be forced
> to NULL? If so, this is not testing the same case - in fact the COPY command
> above just makes explicit the default CSV NULL setting anyway.

I am really not sure if all the purpose of patch can be achieved by
existing syntax, neither it is explained clearly.
However the proposal hasn't discussed why it's not good idea to extend
some similar syntax "COPY .. NULL" which is used to replace string
with NULL's?
Description of NULL says: "Specifies the string that represents a null value."
Now why can't this syntax be extended to support quoted empty string
if it's not supported currently?
I have not checked completely, If it's difficult or not possible to
support in existing syntax, then even it add's more value to introduce
new syntax.

By asking above question, I doesn't mean that we should not go for the
new proposed syntax, rather it's to know and understand the benefit of
new syntax, also it helps during CF review for reviewer's if the
proposal involves new syntax and that's discussed previously.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2013-10-08 04:23:37 Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption
Previous Message Andrew Dunstan 2013-10-08 02:00:23 Re: Bugfix and new feature for PGXS