Fix lockmode initialization for custom relation options

The code was enforcing AccessExclusiveLock for all custom relation
options, which is incorrect as the APIs allow a custom lock level to be
set.

While on it, fix a couple of inconsistencies in the tests and the README
of dummy_index_am.

Oversights in commit 773df88.

Discussion: https://postgr.es/m/20190925234152.GA2115@paquier.xyz
This commit is contained in:
Michael Paquier 2019-09-27 09:31:20 +09:00
parent 8190164e82
commit fbfa566488
4 changed files with 5 additions and 8 deletions

View File

@ -700,13 +700,6 @@ allocate_reloption(bits32 kinds, int type, const char *name, const char *desc,
newoption->type = type;
newoption->lockmode = lockmode;
/*
* Set the default lock mode for this option. There is no actual way
* for a module to enforce it when declaring a custom relation option,
* so just use the highest level, which is safe for all cases.
*/
newoption->lockmode = AccessExclusiveLock;
MemoryContextSwitchTo(oldcxt);
return newoption;

View File

@ -6,6 +6,7 @@ access method, whose code is kept a maximum simple.
This includes tests for all relation option types:
- boolean
- enum
- integer
- real
- strings (with and without NULL as default)

View File

@ -20,6 +20,7 @@ CREATE INDEX dummy_test_idx ON dummy_test_tab
option_bool = false,
option_int = 5,
option_real = 3.1,
option_enum = 'two',
option_string_val = NULL,
option_string_null = 'val');
NOTICE: new option value for string parameter null
@ -32,9 +33,10 @@ SELECT unnest(reloptions) FROM pg_class WHERE relname = 'dummy_test_idx';
option_bool=false
option_int=5
option_real=3.1
option_enum=two
option_string_val=null
option_string_null=val
(5 rows)
(6 rows)
-- ALTER INDEX .. SET
ALTER INDEX dummy_test_idx SET (option_int = 10);

View File

@ -20,6 +20,7 @@ CREATE INDEX dummy_test_idx ON dummy_test_tab
option_bool = false,
option_int = 5,
option_real = 3.1,
option_enum = 'two',
option_string_val = NULL,
option_string_null = 'val');
-- Silence again validation checks for strings until the end of the test.