Skip to content

Add support for testing options/properties on an object #351

@jnasbyupgrade

Description

@jnasbyupgrade

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()).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions