Qore PgsqlSqlUtil Module Reference  1.5
PgsqlSqlUtil Module

PgsqlSqlUtil Module Introduction

The PgsqlSqlUtil module provides a high level API for working with PostgreSQL database objects.

Usually this module is loaded on demand from the SqlUtil module, however to use this module directly, use "%requires PgsqlSqlUtil" in your code.

All the public symbols in the module are defined in the PgsqlSqlUtil namespace

This module requires the pgsql binary module for communication with PostgreSQL databases

Schema Management on PostgreSQL

Type Mapping

Column types are mapped from Qore types as follows:

PostgreSQL Column Type Mappings

Generic Type Name PostgreSQL Type Used
float double
integer bigint
number numeric
string varchar
date timestamp
binary bytea
bool boolean
SqlUtil::BLOB bytea
SqlUtil::CHAR char
SqlUtil::CLOB text
SqlUtil::NUMERIC numeric
SqlUtil::VARCHAR varchar

To use other types, use the "native_type" column description option with the native PostgreSQL type name instead (under the "driver" and "pgsql" keys for schemas supporting multiple databases).

Additional Object Types Supported

The following additional schema objects can be managed with PgsqlSqlUtil:


The Schema Description Hash takes an optional key, "types" that allows types in PostgreSQL schemas to be managed along with other objects.

The "types" should be assigned to a hash, each key name is the name of the type, and the values are strings giving the type definition.

The "types" key can go in the top level of the Schema Description Hash for PostgreSQL-only schemas, or, for schemas targeting multiple database types, under the "driver" and "pgsql" keys as in the following example:

my hash $schema = (
"driver": (
"pgsql": (
"types": (
"info_record": "id numeric, ind numeric, status char",

Function Handling

Function Names and Matching
PostgreSQL functions are identified by their name and arguments; the algorithm implemented in this module is fairly simple; the argument names and types are used when trying to find functions, so they must match almost exactly.

The only exception to the exact matching algorithm is that some simple substitutions are done on user-supplied arguments to try and use the verbose type names as retrieved by pg_catalog.pg_get_function_identity_arguments(), which always returns verbose type names (ie "character varying" instead of "varchar").

Substitutions are made according to the inverse value of PgsqlSqlUtil::PgsqlTable::PgsqlNameMap.

This is done so that a user-supplied function name like "update_queue(qkey varchar, qdata text)" will match the value returned by pg_catalog.pg_get_function_identity_arguments(), which would be "update_queue(character varying queue)"
Schema Management with Functions
There is some simple logic in the driver that attempts to reorder function definitions so that they match the format returned by pg_catalog.pg_get_functiondef() which requires the following string to follow the function name and arguments:
  • returns type language lang as $function$
The logic in the module attempts to move any language and volatility declarations from the end of the declaration to the beginning. Additionally, dollar-quoting is detected automatically and substituted with "$function$" automatically.

If your function is reported as needing updating even though it's already in the database correctly, then the logic in this module needs to be update to provide more flexibility (please report to david.nosp@m.@qor.nosp@m.e.org). Until the module can be enhanced, try the format as in the following example:
update_queue_data(qkey varchar, qdata text) returns integer language plpgsql as $function$
rowcount integer;
update queue_data set data = qdata, queue_data_status = 'R' where queuekey = qkey and queue_data_status = 'W';
get diagnostics rowcount = row_count;
return rowcount;
Future versions of the module may provide more intelligence to reformat user-supplied functions to match the format retrieved from the database, however currently functions should be provided in the format above in order to use functionality like AbstractDatabase::getAlignFunctionSql() for example.

Release Notes

PgsqlSqlUtil v1.5

PgsqlSqlUtil v1.5

  • fixed a bug generating literal date/time values for SQL queries (issue 3948)

PgsqlSqlUtil v1.5

PgsqlSqlUtil v1.3.1

  • fixed compatibility with PostgreSQL 12 (issue 3589)
  • fixed comparison of triggers with column restrictions with table alignment (issue 3466)
  • fixed quoting of reserved words in column names in table alignment (issue 3400)

PgsqlSqlUtil v1.3

PgsqlSqlUtil v1.2.1

  • implemented support for custom column operators (issue 2314)
  • fixed a bug where default column values were compared incorrectly leading to false positives when comparing and aligning DB schemas (issue 2527)

PgsqlSqlUtil v1.2

  • updated for complex types

PgsqlSqlUtil v1.1.2

  • fixed a bug in setting a comment for a table column (issue 1886)
  • implemented cop_trunc_date() operator (issue 2032)

PgsqlSqlUtil v1.1.1

  • implemented the force option (i.e. cascade) for dropping code objects (issue 1314)

PgsqlSqlUtil v1.1

  • added support for cop_cast operator (feature 535)
  • added support for the following datatypes and aliases: bool, float, int, timetz, timestamptz, varbit
  • fixed support for the following datatypes and aliases: bit, bit varying, char, character, character varying, char varying, oid, varchar
  • fixed bugs handling "bigint" and "double precision" column types with schema alignments
  • fixed a bug with PgsqlTable::tryInsertImpl(); added an explicit "begin" call to make the savepoint work with PostgreSQL 9.3+ servers
  • fixed a bug retrieving foreign constraints; columns were not guaranteed to be returned in declaration order
  • implemented support for the "returning" clause as an insert option
  • fixed a bug handling tablespaces in unique constraints
  • fixed bugs in SqlUtil::cop_seq() and SqlUtil::cop_seq_currval() (issue 624)
  • added support for listing PostgreSQL types and materialized views (issue 699)

PgsqlSqlUtil v1.0

  • initial release