3.3. Tables

v1.2.0 Summary Chapter 3: Database objects 3. Introduction 3.3. Tables

No documentation was found matching the provided version! Browsing the latest one.

Tables or entities, in pgModeler, are containers and store several kinds of other objects like columns, constraints, triggers, rules, indexes, policies, and partition keys. These child objects will be fully detailed in the next subsections. The table's editing dialog has the following fields:

Attribute	Description
`Tag`	This attribute is used to configure the tag object associated with the table. Tags are used to graphically separate tables and views even if they are owned by the same schema. Details about tags can be seen further in this chapter in the section Tags.
`With OID`	Specifies if each tuple in the table should have an OID (Object Identifier) associated. This attribute is considered deprecated and is present in pgModeler just for compatibility reasons but its use is discouraged for new models.
`Enable row-level security`	Enables the table's row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted by data modification commands. This option only takes effect if there are policies associated with the table. Refer to section Policies for details.
`Force RLS for owner`	Indicates that the owner of the table should be subject to row-level security. In PostgreSQL, the default behavior is that the table owner normally bypasses RLS.
`Unlogged`	Indicates that the table should not be monitored by the WAL (write ahead log) system.
`Generate ALTER for` `columns/constraints`	This option, when checked, indicates to pgModeler that all columns and constraints must be generated in form of `ALTER TABLE` commands. This is useful when you want to do incremental modeling, that is, create objects in tables that already exist on a running PostgreSQL server. This option was useful when pgModeler lacked the diff tool. Now that the model/database comparing is present, for incremental modeling, we recommend the use of the diff process instead of this option.
`Columns`	This tab lists and allows the handling of all columns associated with the table. Refer to section Columns for details.
`Constraints`	This tab lists and allows the handling of all constraints associated with the table. Refer to section Constraints for details.
`Rules`	This tab lists and allows the handling of all rules associated with the table. Refer to section Rules for details.
`Indexes`	This tab lists and allows the handling of all indexes associated with the table. Refer to section Indexes for details.
`Policies`	This tab lists and allows the handling of all policies associated with the table. Refer to section Policies for details.
`Partition keys`	This tab lists and allows the handling of all partition keys associated with the table. This is used when the table is configured as a partitioned table. Defining a table as partitioned allows the usage of partitioning relationships making other tables be associated as partitions of the former. Refer to section Relationships for details about partitioning relationships.
`Partitioning`	This field is found in the `Partition keys` tab and defines the partitioning strategy adopted by the table. Possible values are `None`, `RANGE`, `LIST`, and `HASH`.
`Tables`	This tab lists all ancestors of the table. Ancestor tables are the ones that are linked to this table through a generalization relationship. Refer to section Relationships for details.