Re: Improving on MAX_CONVERSION_GROWTH - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Improving on MAX_CONVERSION_GROWTH
Date
Msg-id 11114.1570119160@sss.pgh.pa.us
Whole thread Raw
In response to Re: Improving on MAX_CONVERSION_GROWTH  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Improving on MAX_CONVERSION_GROWTH  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Transparent Data Encryption (TDE) and encrypted files
Next
From: Andres Freund
Date:
Subject: Re: fairywren failures