[PATCH] Introduce unified support for composite GUC options - Mailing list pgsql-hackers

Hello hackers,

This patch adds a unified mechanism for declaring and using composite configuration options in GUC, eliminating the need to write a custom parser for each new complex data type.  New syntax for end user is json-like.
Currently, adding a new composite configuration option requires a significant amount of boilerplate code:

1. For DBAs: Learning a new syntax for each composite option.
2. For developers: Implementing a new parser from scratch for each composite type in GUC.

This patch solves these problems by providing a declarative system for defining composite types and their structure.

Major changes:

- guc_tables.h: Added new type config_composite for all composite configuration options.

- guc_composite.c: This file contains all functions related to composite options: calculating alignments, defining field types, working with memory, serialization. The functions from here are used in guc.c and guc_composite_gram.y

- guc.c: New code in this file describes the behavior of the system in the case of PGC_COMPOSITE

- guc_composite_scan.l: guc_composite_gram.y is a lexer and parser for values of composite data types.

Usage features:

Mapping between UI representation and internal variables works due to the signature that the programmer declares for the composite type.  For core options, the declaration data is in the UserDefinedConfigureTypes array. For extensions composite types are declared using the DefineCustomCompositeType function.

All declarations must be arranged topologically. That is, if the type A option contains a type B field, then type B must be declared first, and only after that type A. 

The main fields in the type definition are the type name and its signature.

The type signature has the following syntax:

“field_type field_name; field_type field_name; ...; field_type field_name”

where field_type is the already registered type, field_name is the field name.

There are also data types that do not need to be declared - these are arrays. So, if there is a registered type A, then the following data types automatically become available: A[n] is a static array of length n and A[] is a dynamic array. 

Note that the declared type signature must exactly match the signature of the structure in the C code, since it will then be used to calculate the alignment of fields according to the rules of the C language.

Dynamic arrays are always mapped into a structure like:

struct DynArr {

void *data; //pointer to data

int size; //length of the array

}

After declaring the type definition, you can declare a composite type configuration option. The core options are declared in the guc_parameters.dat file. They must specify the type => ‘composite’ fields and specify in the type_name field the name of the composite type that was declared earlier. In the boot_val field, write a pointer to a global variable that will store this value. Options from extensions are declared using DefineCustomCompositeVariable.

Now you can use the following syntax to work with the new options both in the configuration file and in psql:

Access field of the struct: option_name->field_name

Access to an array element: option_name[index]

You can combine these access methods.

Dynamic arrays always have implicit fields data and size. data is the data of the array, size is its length.

Values of composite types have the following syntax:

Structures: {field: value, ..., field: value}

Static arrays: [index: value, index: value]

As mentioned earlier, dynamic arrays have implicit fields, so you can use 2 syntaxes to set values.:

compact (same as for static arrays) and extended:

{data: [index: value, .., index: value], size: value}.

It is not necessary to write indexes in array values. If you write without indexes, it is assumed that indexing starts from 0 with an increment of 1. In this case, all elements within the same array must be either with or without indexes.

When using the show command, the display of the dynamic array depends on the extended_guc_arrays option. If this flag is true, then the extended form is used, otherwise the compact form is used.

String values within composite types also support escape sequences.

All the functionality available to scalar options is also supported, such as: …

The system uses incremental semantics. This means that when writing to a .conf file or the set command, only the specified fields of the structure will be changed, the remaining fields will not be involved. This semantics also applies to the ALTER SYSTEM. When using ALTER SYSTEM, the current value will be written to the .auto.conf file with the changed fields that were described when calling the command, while the current value of the option will not change.

The patch applies cleanly to the master (454c046094ab3431c2ce0c540c46e623bc05bd1a).

In the additional patch (guc_composite_types_tests.patch), I added several composite options so that the new functionality could be tested using their example. Regression and TAP tests were written for them in the same patch.

I would appreciate any feedback and review.

Best regards,
Anton Chumak