Re: Unit tests for SLRU
От | Aleksander Alekseev |
---|---|
Тема | Re: Unit tests for SLRU |
Дата | |
Msg-id | CAJ7c6TP+4FquwzZ_FGdLgRK2YRz9K76RAA7e6JnQkEbOT1GUwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Unit tests for SLRU (Pavel Borisov <pashkin.elfe@gmail.com>) |
Ответы |
Re: Unit tests for SLRU
|
Список | 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
Again, I don't have a strong opinion here. If you insist, I will place the tests to regress.c.
--
Best regards,
Aleksander Alekseev
> 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
В списке pgsql-hackers по дате отправления: