|From:||Paul Ramsey <pramsey(at)cleverelephant(dot)ca>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Regina Obe <r(at)pcorp(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Compressed TOAST Slicing|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On Mar 18, 2019, at 7:34 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Mar 18, 2019 at 10:14 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>>> * Andres Freund (andres(at)anarazel(dot)de) wrote:
>>>> I don't think that should stop us from breaking the API. You've got to
>>>> do quite low level stuff to need pglz directly, in which case such an
>>>> API change should be the least of your problems between major versions.
>>> Agreed, this is across a major version and I don't think it's an issue
>>> to break the API.
>> Yeah. We don't normally hesitate to change internal APIs across major
>> versions, as long as
>> (a) the breakage will be obvious when recompiling an extension, and
>> (b) it will be clear how to get the same behavior as before.
>> Adding an argument qualifies on both counts. Sometimes, if a very
>> large number of call sites would be affected, it makes sense to use
>> a wrapper function so that we don't have to touch so many places;
>> but that doesn't apply here.
> +1. I think Paul had it right originally.
In that spirit, here is a “one pglz_decompress function, new parameter” version for commit.
|Next Message||Robert Haas||2019-03-18 15:31:26||Re: BUG #15641: Autoprewarm worker fails to start on Windows with huge pages in use Old PostgreSQL community/pgsql-bugs x|
|Previous Message||Robert Haas||2019-03-18 14:54:19||Re: Unduly short fuse in RequestCheckpoint|