On Tue, Jan 16, 2024 at 6:15 AM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote:
> On Tue, Jan 16, 2024 at 10:28 AM Michael Paquier <mich...@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? > Hi, One idea I wanted to implement is a table access method that you can use to test the interface, something like a "mock TAM" where you can programmatically decide on the responses to unit-test the API. I was thinking that you could implement a framework that allows you to implement the TAM in some scripting language like Perl, Python, or (horrors) Tcl for easy prototyping. Best wishes, Mats Kindahl > -- > Bharath Rupireddy > PostgreSQL Contributors Team > RDS Open Source Databases > Amazon Web Services: https://aws.amazon.com > > >
