7.14. Creating stub objects

In pgModeler, it is possible to create objects that exist both in the database and in the model, but whose SQL code is not generated when the model is exported. Such objects are commonly known as stub objects: they work as placeholders that materialize, in the model, an object that already exists in the database but that doesn't necessarily need to have its code generated. Their purpose is to serve as references to other objects being created on the database model. Examples of stub objects are the schemas public and pg_catalog, the tablespaces pg_default and pg_global, the languages c, internal, sql, and plpgsql, and the role postgres. These objects are automatically created by pgModeler when a new model is added. At the moment an SQL export process occurs, their SQL definition will be completely ignored or, in other words, they will not be created on the server even if they are present in the database model.

This feature is quite handy when you need to create additional objects in an already existing database. You can create objects that match the ones in the database and check the option Disable SQL code on their respective editing forms, or use the same action available in the Quick actions menu (Disable SQL) to turn them into stub objects. When an object has its SQL disabled, the same menu shows the item Enable SQL, which reverts it.

Once the stub objects are created, you can proceed with the export process and see only the objects with SQL code enabled being created. The stub ones will not be exported because their code, internally, is commented causing PostgreSQL to ignore them. The stub objects are ignored in the same way by the diff process which does not produce diff code for them.

To clarify the concept of stub objects, let's use a practical example: assuming that we need to create a new table called table_a on a database that exists on the server, the table must reference another one called table_b, and again, this last object already exists on the server-side. Our model will look like the image below, where table_b has its SQL code disabled.

It is important to note at this point that, in practice, only table_a and its children will be exported, while the referenced stub object table_b will not. In pgModeler, stub objects will have their names with a strike-out font style in the model objects widget and for graphical stub objects, the SQL off label is attached to them to denote the disabled SQL status as shown in the image.