Horton

Re: Compressed TOAST Slicing

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Paul Ramsey <pramsey@cleverelephant.ca>
Cc: Andres Freund <andres@anarazel.de>, Regina Obe <r@pcorp.us>, pgsql-hackers@lists.postgresql.org
Date: 2019-03-13T01:58:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add support for partial TOAST decompression

  2. Remove remaining hard-wired OID references in the initial catalog data.

  3. Rephrase references to "time qualification".

On Tue, Mar 12, 2019 at 11:08:15AM -0700, Paul Ramsey wrote:
>> On Mar 12, 2019, at 9:45 AM, Paul Ramsey <pramsey@cleverelephant.ca> wrote:
>> I was going to say that the function is only used twice in the code
>> base, but I see it’s now used four times. So maybe leave the old
>> signature in place and add the new one for my purposes after
>> all. Though with only four internal calls, I am guessing Michael is
>> more concerned about external users than with internal ones?

Yes, external tools are the part I worry about.  It is better to avoid
breaking compatibility if there are workarounds we can apply.  Now I
agree that this particular one may not be the most used ever in the
community ecosystem.

> So…
> - two signatures?
> - old signature but reduced error checking?
> - elephant?

I have not looked at how much effort it would be to keep the current
API and still make the slicing happy, sorry ;p

One way to sort things out would be to have a new _extended() API
layer which is able to take a set of custom flags with one extra
argument, using bits16 for example.  This way, your new option becomes
a flag in an extensible set, and we don't need to worry about breaking
the API again in the future if more options are added.
--
Michael