Re: A worst case for qsort

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: A worst case for qsort
Дата
Msg-id alpine.DEB.2.10.1408060838090.24380@sto
обсуждение исходный текст
Ответ на A worst case for qsort  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: A worst case for qsort  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
> For example, if we had reason to be concerned about *adversarial* 
> inputs, I think that there is a good chance that our qsort() actually 
> would be problematic to the point of driving us to prefer some generally 
> slower alternative.

That is an interesting point.

Indeed, a database in general often stores user-supplied data, which may 
happen to be sorted for presentation purpose in an interface. Same thing 
occured with hashtable algorithms and was/is a way to do DOS attacks on 
web applications. I'm not sure whether the qsort version discussed here 
would apply on user-supplied data, though. If so, adding some randomness 
in the decision process would suffice to counter the adversarial input 
argument you raised.

-- 
Fabien.



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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: missing PG_RETURN_UINT16
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: A worst case for qsort