GetSchema("DataTypes") gets CreateFormat and CreateParameters wrong for the character types. A CreateFormat is the "format string that represents how to add this column to a data definition statement, such as CREATE TABLE", but:

PopulateHardcodedDataTypeInfo switches on PostgresType.Name, the display name, so case "varchar" never matches (character varying) and case "char" matches the internal one-byte "char" type (OID 18), not bpchar. Both fall through to case "text", which is where the size was added, so only text and "char" got one.

This takes the modifier from the server instead. pg_type.typmodin is how PostgreSQL itself decides whether a type takes a modifier: text has none, which is why text(10) fails. GetDataTypes reads it once (SELECT oid, typmodin::text FROM pg_catalog.pg_type) and adds the modifier after the type's internal name (VARCHAR({0}), BPCHAR({0}), TIMESTAMPTZ({0}), NUMERIC({0},{1})). Parameter names come from the typmodin function, so only the built-in ones are recognised; an extension's modifier is left out, as before. The query is skipped below PostgreSQL 8.3 (where typmodin arrived), on Redshift, and when type loading is off, since a failed query would abort the caller's transaction. Because it now queries, GetDataTypes follows the async path like the other collections.

Tests, which fail on main:

• DataTypes_CreateFormat_is_accepted_with_its_parameters creates a column from every row that has CreateParameters.
• DataTypes_CreateFormat_has_a_modifier_when_the_type_takes_one pins the expected format per type, including arrays.
• DataTypes_DataType_matches_the_type_read_for_types_with_a_modifier checks that DataType is what the reader returns for such a column.

All SchemaTests pass against PostgreSQL 17 (234). The query also runs on CockroachDB (which reports 0 rather than - for no modifier) and on Spanner through PGAdapter.

On Spanner

Selecting from pg_type.typmodin is the right rule, and Spanner is the problem:

• Real PostgreSQL: typmodin is how PostgreSQL itself decides whether a type takes a modifier. text(10) fails precisely because text has no typmodin, so the rule is accurate by construction.
• Spanner: it copies PostgreSQL's pg_type rows and keeps numerictypmodin, timestamptztypmodin and intervaltypmodin, then refuses those modifiers ("Type modifier is not supported for type numeric"). A catalog that advertises abilities the server rejects is a catalog bug, and every tool that reads pg_type is misled by it, not just Npgsql.
• The current switch isn't more correct on Spanner, only differently wrong: it gets TEXT and NUMERIC wrong there today, and text, char, varchar and bpchar wrong on real PostgreSQL.

The internal "char" type is handled in a separate PR, since its CreateFormat needs quoting rather than a modifier.

Found with the pengdows ADO.NET conformance suite, whose type-fidelity tests create a column from each DataTypes row and round-trip values through it.

🤖 Generated with Claude Code