Re: utf8 COPY DELIMITER?

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: utf8 COPY DELIMITER?
Дата
Msg-id 462650C0.1050601@dunslane.net
обсуждение исходный текст
Ответ на Re: utf8 COPY DELIMITER?  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-hackers
Jim C. Nasby wrote:
> On Tue, Apr 17, 2007 at 02:28:18PM -0400, Tom Lane wrote:
>   
>> I doubt that supporting a single multibyte character would be an
>> interesting extension --- if we wanted to do anything at all there, we'd
>> just generalize the delimiter to be an arbitrary string.  But it would
>> certainly slow down COPY by some amount, which is an area where you'll
>> get push-back for performance losses, so you'd need to make a convincing
>> use-case for it.
>>     
>
> Couldn't we use a fast code path (what we have now) for the case when
> the delimiter is a single byte? That would allow for multi-character
> delimiters without penalizing those that don't use them.
>
> As for use case, I worked on migrating some stuff out of a MySQL
> database a while ago, and having arbitrary string delimiters would have
> made life easier.
>   

The first thing to note is that the COPY code is quite complex and 
fragile. Personally, I'd want a heck of a lot of convincing to see it 
changed, and your use case looks to me like it would be better handled 
by preprocessing using a perl script.

Also, if we accept string delimiters on input, we should also allow them 
on output.

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Background LRU Writer/free list
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [RFC] PostgreSQL Access Control Extension (PGACE)