From: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, rey <reywang(at)optonline(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: psql copy command - 1 char limitation on delimiter |
Date: | 2010-10-18 20:10:11 |
Message-ID: | 4CBCA9A3.6020608@pinpointresearch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/12/2010 08:28 PM, Bruce Momjian wrote:
> Steve Crawford wrote:
>
>> On 09/25/2010 07:03 AM, Tom Lane wrote:
>>
>>> rey<reywang(at)optonline(dot)net> writes:
>>>
>>>
>>>> Why limit this to a single character?
>>>>
>>>>
>>> Performance. Believe it or not, breaking fields at the delimiter is
>>> a significant factor in COPY speed.
>>>
>>> regards, tom lane
>>>
>>>
>>>
>> I agree that that multi-character (or even regex) delimiters would be
>> useful. Would it be reasonable for the copy process to differentiate
>> between single character delimiters which could be processed in
>> "high-speed" mode and multi-character or regex delimiters which would be
>> available as needed albeit at the expense of a performance hit?
>>
> I am not sure you are aware but Postgres never confuses delimiters from
> data because it uses a backslash before literal data that matches
> delimiters.
>
>
Yes, I am. But the discussion was about using multi-character strings as
delimiters.
But while I have encountered files using multiple-character delimiters,
I'm finding myself leaning toward the camp that says that such cases are
better processed externally by Perl/Python/sed/awk/Ruby/ETL/etc.
Especially given the "fun" of defining how to properly escape a
regex-matching string in a regex delimited file.
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Turner, John J | 2010-10-18 21:58:38 | Re: installing from source in Windows |
Previous Message | Joshua D. Drake | 2010-10-18 18:08:00 | PgWest 2010: Two weeks away |