Re: Unit tests for SLRU
Aleksander Alekseev <aleksander@timescale.com>
From: Aleksander Alekseev <aleksander@timescale.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Pavel Borisov <pashkin.elfe@gmail.com>, Noah Misch <noah@leadboat.com>, Daniel Gustafsson <daniel@yesql.se>
Date: 2022-04-05T09:38:48Z
Lists: pgsql-hackers
Hi Daniel, > It also doesn't seem all that appealing that SimpleLruInit can > return false on successful function invocation, it makes for a confusing API. Agree. I think using an additional `bool *found` argument would be less confusing. Noah, Pavel, >> The default place for this kind of test is regress.c, with plain "make check" >> calling the regress.c function. src/test/modules is for things requiring an >> extension module or otherwise unable to run through regress.c. > > +1 for placement c functions into regress.c if it's possible for the aim of simplification. Thanks for your feedback. I'm OK with placing the tests to regress.c, but I would like to double-check if this would be a right place for them. I'm reading src/test/modules/README and it says: """ src/test/modules contains PostgreSQL extensions that are primarily or entirely intended for testing PostgreSQL and/or to serve as example code. [...] If you're adding new hooks or other functionality exposed as C-level API this is where to add the tests for it. """ SLRU looks like a quite general-purpose container. I can imagine how someone may decide to use it in an extension. Wouldn't it be more logical to place it near: src/test/modules/test_rbtree src/test/modules/test_shm_mq ... etc? Again, I don't have a strong opinion here. If you insist, I will place the tests to regress.c. -- Best regards, Aleksander Alekseev
Commits
-
Add test module for SLRUs
- 006b69fd912b 16.0 landed
-
Fix comment of SimpleLruInit() in slru.c
- 9e0321135cae 14.7 landed
- 5962c8cbe5a6 15.2 landed
- 5ca3645cb3fb 16.0 landed