Re: Add test module for Table Access Method
Japin Li <japinli@hotmail.com>
From: Japin Li <japinli@hotmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Jelte Fennema-Nio <postgres@jeltef.nl>, Aleksander Alekseev <aleksander@timescale.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Fabrízio de Royes Mello <fabriziomello@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-01-16T06:15:21Z
Lists: pgsql-hackers
On Tue, 16 Jan 2024 at 13:15, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > On Tue, Jan 16, 2024 at 10:28 AM Michael Paquier <michael@paquier.xyz> wrote: >> >> Hmm. I'd rather have it do something useful in terms of test coverage >> rather than being just an empty skull. >> >> How about adding the same kind of coverage as dummy_index_am with a >> couple of reloptions then? That can serve as a point of reference >> when a table AM needs a few custom options. A second idea would be to >> show how to use toast relations when implementing your new AM, where a >> toast table could be created even in cases where we did not want one >> with heap, when it comes to size limitations with char and/or varchar, >> and that makes for a simpler needs_toast_table callback. > > I think a test module for a table AM will really help developers. Just > to add to the above list - how about the table AM implementing a > simple in-memory (columnar if possible) database storing tables > in-memory and subsequently providing readers with the access to the > tables? That's a good idea.