Re: [PATCH] Check that index can return in get_actual_variable_range()
| От | Peter Eisentraut | 
|---|---|
| Тема | Re: [PATCH] Check that index can return in get_actual_variable_range() | 
| Дата | |
| Msg-id | 2cc73c0a-e0dd-4f98-be9f-469c4f1df65e@eisentraut.org обсуждение исходный текст  | 
		
| Ответ на | Re: [PATCH] Check that index can return in get_actual_variable_range() (Maxime Schoemans <maxime.schoemans@enterprisedb.com>) | 
| Ответы | 
                	
            		Re: [PATCH] Check that index can return in get_actual_variable_range()
            		
            		 | 
		
| Список | pgsql-hackers | 
On 22.09.25 16:38, Maxime Schoemans wrote: > On 19 Sep 2025, at 10:20, Aleksander Alekseev <aleksander@tigerdata.com> > wrote: > >> Yes, this is how we typically test cases like this. IMO adding a test >> module would be helpful. It can be reused for other scenarios. > > Here is an updated patch set. > - 0001 is unchanged. > - 0002 contains the module that tests the correct behavior of > get_actual_variable_range for non-returning ordering indices. > It contains a copy of the btree handler function with its index-only > capabilities removed. If you apply patch 0002 on master without 0001, > you will see that the test returns an error (ERROR: no data returned > for index-only scan) as it tries to use the index in > get_actual_variable_range, which shouldn’t be the case. I have committed the first patch. The test suite is probably a bit too bulky for testing this particular niche behavior. Also, it doesn't work with assertions enabled because of the hardcoded BTREE_AM_OID in src/include/access/nbtree.h. So I don't plan to commit that. But it's good to have it in the archive, and perhaps it can be part of a larger test suite for the index AM API at some point in the future.
В списке pgsql-hackers по дате отправления: