Re: Improving on MAX_CONVERSION_GROWTH

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Improving on MAX_CONVERSION_GROWTH
Дата
Msg-id 11114.1570119160@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Improving on MAX_CONVERSION_GROWTH  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Improving on MAX_CONVERSION_GROWTH
Список pgsql-hackers
I wrote:
> In the meantime, I still think we should commit what I proposed in the
> other thread (<974.1569356381@sss.pgh.pa.us>), or something close to it.
> Andres' proposal would perhaps be an improvement on that, but I don't
> think it'll be ready anytime soon; and for sure we wouldn't risk
> back-patching it, while I think we could back-patch what I suggested.
> In any case, that patch is small enough that dropping it would be no big
> loss if a better solution comes along.

Not having heard any objections, I'll proceed with that.  Andres is
welcome to work on replacing it with his more-complicated idea...

> Also, as far as the immediate subject of this thread is concerned,
> I'm inclined to get rid of MAX_CONVERSION_GROWTH in favor of using
> the target encoding's max char length.

I realized after re-reading the comment for MAX_CONVERSION_GROWTH that
this thread is based on a false premise, namely that encoding conversions
always produce one "character" out per "character" in.  In the presence of
combining characters and suchlike, that premise fails, and it becomes
quite unclear just what the max growth ratio actually is.  So I'm going
to leave that alone for now.  Maybe this point is an argument for pushing
forward with Andres' approach, but I'm still dubious about the overall
cost/benefit ratio of that concept.

            regards, tom lane



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Transparent Data Encryption (TDE) and encrypted files
Следующее
От: Andres Freund
Дата:
Сообщение: Re: fairywren failures