phalcon/cphalcon · error · UnrecognizedDataType

Unrecognized PostgreSQL data type at column {}

Error message

Unrecognized PostgreSQL data type at column {}

What it means

The PostgreSQL dialect's column compiler throws UnrecognizedDataType (message names PostgreSQL) when a Column's type constant reaches the default branch of the type switch with no column SQL produced. The Column was built with a type unknown to this dialect — a raw integer, a constant from a different Phalcon version, or one not applicable to PostgreSQL — so the dialect refuses to invent a PostgreSQL type.

Source

Thrown at phalcon/Db/Dialect/Postgresql.zep:786

                break;

            case Column::TYPE_MULTIPOLYGON:
                if empty columnSql {
                    let columnSql .= "MULTIPOLYGON";
                }

                break;

            case Column::TYPE_GEOMETRYCOLLECTION:
                if empty columnSql {
                    let columnSql .= "GEOMETRYCOLLECTION";
                }

                break;

            default:
                if unlikely empty columnSql {
                    throw new UnrecognizedDataType("PostgreSQL", column->getName());
                }

                let typeValues = column->getTypeValues();
                if !empty typeValues {
                    if typeof typeValues == "array" {
                        var value;
                        string valueSql;

                        let valueSql = "";

                        for value in typeValues {
                            let valueSql .= "'" . addcslashes(value, "\'") . "', ";
                        }

                        let columnSql .= "(" . substr(valueSql, 0, -2) . ")";
                    } else {
                        let columnSql .= "('" . addcslashes(typeValues, "\'") . "')";
                    }

View on GitHub (pinned to b7419de9cd)

Solutions

1. Use PostgreSQL-supported constants, e.g. Column::TYPE_SERIAL, TYPE_JSONB/TYPE_JSON, TYPE_VARCHAR, TYPE_TIMESTAMP — verify against your Phalcon\Db\Column
2. Reference constants by name, never by integer, in migrations
3. Per-adapter column-type mapping tables in shared schema code, validated before DDL generation

Example fix

// before
$column = new Column('data', ['type' => 999]);

// after
$column = new Column('data', ['type' => Column::TYPE_JSONB]);

if (!in_array($column->getType(), $allowedPostgresTypes, true)) {
    throw new InvalidArgumentException('Column type not supported by the PostgreSQL dialect: ' . $column->getName());
}

function pgColumn(string $name, int $type, array $definition = []): \Phalcon\Db\Column
{
    // Only accept named constants; reject 0/negative/unknown integers early.
    if ($type < 1 || !in_array($type, $knownTypeConstants, true)) {
        throw new InvalidArgumentException("Unknown column type for {$name}");
    }
    return new \Phalcon\Db\Column($name, $definition + ['type' => $type]);
}

try {
    $connection->createTable($table, 'public', $definition);
} catch (\Phalcon\Db\Exceptions\UnrecognizedDataType $e) {
    throw new RuntimeException("DDL rejected for {$table}: " . $e->getMessage(), 0, $e);
}

When it happens

Trigger: new Column('data', ['type' => 999]) in a Postgres createTable()/addColumn() call; sharing column-definition factories across MySQL and PostgreSQL where one side uses constants the other dialect never matches; Column objects unserialized with a stale type value.

Common situations: Multi-database model metadata reused across adapters; version skew between the Phalcon version that defined new TYPE_* constants and the dialect implementation; hand-written migration arrays with numeric types.

Related errors

• Unrecognized MySQL data type at column {}
• The index 'columns' is required in the definition array
• The table must contain at least one column
• The index 'columns' is required in the definition array
• The index 'sql' is required in the definition array

AI-assisted analysis of phalcon/cphalcon@b7419de9cd (2026-08-21). Data as JSON: /api/errors/736286e3628a1924. Report an issue: GitHub.