Josh Berkus wrote:
> Greg,
>
>
>> The performance of every path to get data into the database besides COPY
>> is too miserable for us to use anything else, and the current
>> inflexibility makes it useless for anything but the cleanest input data.
>>
>
> One potential issue we're facing down this road is that current COPY has
> a dual purpose: for database restore, and for importing and exporting
> data. At some point, we may want to separate those two behaviors,
> because we'll be adding bells and fringes to import/export which slow
> down overall performance or add bugs.
>
>
Nothing that has been proposed will slow down existing behaviour AFAIK.
The new behaviour will be slower in most cases, but that's a different
matter.
cheers
andrew
