-
Notifications
You must be signed in to change notification settings - Fork 104
Description
Several types of objects support setting various options, such as CREATE TABLE ... WITH () and CREATE FUNCTION ... SET. There's also things like options for generated columns, as discussed in #321. While I don't think there's any rocket science to adding the actual checks, one thing that gives me pause is what argument type to use for the actual options.
As far as I know, all the catalogs store options the same way: as a text array where the elements alternate between the name of an option and the value for that option. While we should probably support that as an input type as well, it's always struck me that using that format as an API is at least error prone. I'd like to propose that we support at least one other allowed type of input, so that we don't accidentally lock the pgTap API into supporting only text[]. JSON(b) is an obvious alternative.
I'd also like to propose that we support text[][], defined as an array of {option_name, option_value}. For example...
SELECT function_settings_are( 'myfunc' , array['int','int'] , $${{search_path, pg_catalog}, {enable_indexscan, off}}$$ );
Note that no matter what we do here we should not depend on the ordering of options in the catalog. We should have a common internal test function that does the equivalent of bag_eq(). That function can also be responsible for differentiating between the passed-in options being a 1 or 2 dimensional array (using array_ndims()).