Versions of Metadata
The relational interface in Pervasive PSQL supports two versions of metadata, referred to as version 1 (V1) and version 2 (V2).
Metadata version is a property of the database that you specify when you create a database. V1 metadata is the default. When you create a database, you must specify V2 metadata if you want that version.
Metadata version applies to all data dictionary files (DDFs) within that database. A single database cannot use some DDFs with V1 metadata and others with V2 metadata. DDFs from the two versions cannot interact.
The database engine can, however, concurrently access multiple databases and each database can use either V1 metadata or V2 metadata.
All databases created with Pervasive PSQL versions prior to Pervasive PSQL v10 use V1 metadata. Databases created with Pervasive PSQL v10 or later may use either metadata version depending on the database settings.
Comparison of Metadata Versions
Version 2 metadata allows for many identifier names to be up to 128 bytes long. Refer to
Limits/Conditions of Pervasive PSQL Features
for additional information. In addition, V2 metadata allows for permissions on views and stored procedures. See
Permissions on Views and Stored Procedures
.
The data dictionary files (DDFs) for V2 metadata are named differently than for V1. In many cases, the V2 DDFs contain additional fields and changes to existing fields. See
System Tables
.
Conversion Utility
Pervasive PSQL includes a conversion utility, pvmdconv, to convert V1 metadata to V2 metadata. See
pvmdconv
in
Pervasive PSQL User's Guide
.
Relational Interface Limits
The following table shows the limits or conditions that apply to features of the relational interface.
A Pervasive PSQL database may contain four billion objects in any valid combination. The objects are persisted in the data dictionary files.
See also
Naming Conventions
in
Pervasive PSQL Programmer's Guide
in the Developer Reference.
Table 19
Limits/Conditions of Pervasive PSQL Features
Pervasive PSQL Feature
Limit or Condition
Metadata
V1
V2
Arguments in a parameter list for a stored procedure
300
CHAR column size
8,000 bytes
1
Character string literal
A character in the string may be any ANSI character between 1 and 255 decimal.
Columns in a table
1,536
Columns allowed in a trigger or stored procedure
300
Column name
2
20 bytes
128 bytes
Column size
2 GB
Correlation name
limited by memory
Cursor name
18 bytes
Database name
2
20 bytes
Database sessions
limited by memory
Data file path name
64 bytes (the maximum length of the data file path name is a combination of Xf$Loc path and the data file path)
250 bytes (the maximum length of the data file path name is a combination of Xf$Loc path and the data file path)
Function (user-defined) name
2
30 bytes
128 bytes
Group name
2
30 bytes
128 bytes
Index name
2
20 bytes
128 bytes
Key name
2
20 bytes
128 bytes
Label name
limited by memory
Number of ANDed predicates
300
Number of database objects
65,536
2 billion
Parameter name
126 bytes
Password
2
8 bytes
128 bytes
Procedure name
2
30 bytes
128 bytes
Referential integrity (RI) constraint name
20 bytes
128 bytes
Representation of single quote
Two consecutive single quotes (‘‘)
Result name
limited by memory
Savepoint name
limited by memory
SELECT list columns in a query
1,600
Size of a single term (quoted literal string) in an SQL statement
14,997, excluding null terminator and quotations (15,000 total)
SQL statement length
64 KB
SQL statements per session
limited by memory
Stored procedure size
64 KB
Table name
2
20 bytes
128 bytes
Table rows
2 billion
Joined tables per query
limited by memory
Trigger name
2
20 bytes
128 bytes
User name
2
30 bytes
128 bytes
VARCHAR column size
8,000 bytes
1
Variable name
limited by memory
View name
2
20 bytes
128 bytes
1
The maximum size of a CHAR or VARCHAR column that may be fully indexed is 255 bytes
2
See also
Identifier Restrictions by Identifier Type
in
Advanced Operations Guide
.
Fully Qualified Object Names
A fully qualified object name combines the name of the database and the object using dot notation. For example, if you have a view named myview in database mydbase, the fully qualified object name is mydbase.myview.
Fully qualified object names need to be unique within a database. For example, suppose in database “mydbase,” you name a table “acctpay” and a user-defined function (or any other object) “acctpay.” The fully qualified name is “mydbase.acctpay,” in which case Pervasive PSQL does not know to which object the name refers.
