The PostgreSQL documentation Appendix K states a table can have a maximum of 1,600 columns.
This is a hard coded limit that can be found in the source code at src/include/access/htup_details.h:
#define MaxTupleAttributeNumber 1664
#define MaxHeapAttributeNumber 1600Let’s fully validate the claim and test accordingly.
Here, we’ll use a simple bash script because it is easy to adapt while testing.
-- Classic example
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1601;';
EXECUTE 'CREATE TABLE tint_1601(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tint_1601 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;The typical output is as follows:
NOTICE: table "tint_1600" does not exist, skipping
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tint_1600 ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTESo far so good (or at least, all is working as expected).
You might have the idea to try replacing int4 with int2 type to create a 1,600+ column table. It will not work as this is a hard coded limit.
Let’s build a 1,600 column table with the same demonstrated code.
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;Another sql script can be used to produce a valid 1,600 column tuple:
DO $$
DECLARE
s TEXT;
rows_inserted int;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( ',1' , 1599 )
);
EXECUTE s;
GET DIAGNOSTICS rows_inserted = ROW_COUNT;
RAISE NOTICE 'Rows inserted: %', rows_inserted;
END $$;The output is:
NOTICE: Rows inserted: 1
DOAnother success with no surprise.
Let us continue pushing to the limits.
We now create another 1,600 column table using the char(127) data type.
We reuse our sql script with some modifications:
-- Create a table with 1,600 columns: 1 x int + 1599 x char(127)
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN c_%s char(127) NOT NULL;', i);
END LOOP;
END $$;
-- Insert a tuple - 1 x int + 1599 x char(127)
DO $$
DECLARE
s TEXT;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( $q$,'1'::char(127)$q$ , 1599 )
);
EXECUTE s;
END $$;The output is:
ERROR: row is too big: size 25616, maximum size 8160As we can see, the table has 1,600 columns but this time the tuple cannot fit a single heap page which explains the error “row is too big: size 25616, maximum size 8160”. If you paid attention to the modified script, you can see columns are defined as NOT NULL so at table creation PostgreSQL could have proven data insertion was impossible.
To keep things simple, let us auto-join:
SELECT a.*,b.* FROM tint_1600 a, tint_1600 b;
ERROR: target lists can have at most 1664 entriesNow the SELECT clause (a.*,b.*) is reaching its own limit (MaxTupleAttributeNumber = 1664).
Sometimes, you have to modify your application and it generates schema modifications.
Most of the time, there are table modifications like adding or dropping columns.
ADD / DROP COLUMNLet us see what happens from the SQL side when we add, then drop, a column.
=# CREATE TABLE tadc_1600(i_1 int NOT NULL);
CREATE TABLE
=# ALTER TABLE tadc_1600 ADD COLUMN i_2 int NOT NULL;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
i_2 | 2 | p | t | f
(2 rows)
=# ALTER TABLE tadc_1600 DROP COLUMN i_2;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
(2 rows)When dropping a column,
One can wonder if there is a limit to the number of add/drop operations that can be run on a given table.
As usual, let us try:
-- ADD / DROP COLUMN example
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tadc;';
EXECUTE 'CREATE TABLE tadc(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tadc ADD COLUMN i_%s int;', i);
EXECUTE format('ALTER TABLE tadc DROP COLUMN i_%s;', i);
END LOOP;
END $$;The output is:
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tadc ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTEOh oh! We reached the 1,600 limit here as well.
Let us explore a bit after add/drop column 1,599 times:
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
........pg.dropped.3........ | 3 | p | f | t
........pg.dropped.4........ | 4 | p | f | t
........pg.dropped.5........ | 5 | p | f | t
........pg.dropped.1599........ | 1599 | p | f | t
........pg.dropped.1600........ | 1600 | p | f | t
(1600 rows)Well, table tadc has 1,600 columns. You can see this as modifications are appending and table content rewriting is avoided.
At this point, further column add & drop modifications will fail.
Is there anything I can do to escape this situation?
The VACUUM command operates at the tuple level so even if you run a VACUUM FULL the table structure will not change.
This is not an issue with dead tuples but rather an issue with the catalog.
You’ll need to create a new table definition.
Here are some solutions, from simple to complex:
Build a new table (requires service downtime)
CREATE TABLE (LIKE INCLUDING ALL)COPY data from old to new tableLeverage logical replication (minimize service downtime)
CREATE TABLE LIKE (INCLUDING ALL)CREATE local PUBLICATION/SUBSCRIPTIONThe above solution works fine for simple cases. But real life tables often
use integrity constraints. Let’s explore a bit using foreign keys.
-- Foreign key case
=# CREATE TABLE colors (id int, name text );
=# CREATE TABLE objects ( id int, color_id int, name text );
=# ALTER TABLE colors ADD PRIMARY KEY (id);
=# ALTER TABLE objects ADD CONSTRAINT fk_color
FOREIGN KEY (color_id) REFERENCES colors (id);
=# INSERT INTO colors
VALUES (1,'red'), (2, 'green'), (3, 'blue' );
=# INSERT INTO objects
VALUES (1,1, 'red object')
,(2,2, 'green object')
,(3,3,'blue object');Let’s apply the recipe:
-- Duplicate table structure (valid columns only) and copy data
=# CREATE TABLE tmp_colors (LIKE colors INCLUDING ALL);
=# INSERT INTO tmp_colors SELECT * FROM colors;
-- Do the DROP/RENAME trick
=# BEGIN;
=# DROP TABLE colors;
=# ALTER TABLE tmp_colors RENAME TO colors;
=# COMMIT;The DROP TABLE command issued an error:
ERROR: cannot drop table colors because other objects depend on it
DETAIL: constraint fk_color on table objects depends on table colors
HINT: Use DROP ... CASCADE to drop the dependent objects too.As we can see, the recipe has to be changed to include dependent tables as well.
Adding CASCADE will drop FK constraints on dependent tables.
Let’s run a modified version of the recipe:
-- Do the DROP/RENAME trick
=# BEGIN;
=# DROP TABLE colors CASCADE; -- DROP related FOREIGN KEY constaints
=# ALTER TABLE tmp_colors RENAME TO colors;
-- Recreate FK contraint
=# ALTER TABLE objects ADD CONSTRAINT fk_color
FOREIGN KEY (color_id) REFERENCES colors (id);
COMMIT;We have to check the behaviour is the expected one:
=# INSERT INTO objects VALUES (5,5,'ro');
ERROR: insert or update on table "objects" violates foreign key constraint "fk_color"
DETAIL: Key (color_id)=(5) is not present in table "colors".
=# INSERT INTO objects VALUES (5,3,'ro');
INSERT 0 1Success!
When integrity constraints are too numerous or you find it difficult to follow,
you may use pg_dump/pg_restore to rebuild all automatically. If service downtime
is an issue, you may use logical replication to perform like pg_dump/pg_restore.
As you can see, having to deal with the 1,600 column limit is not something you would
like to do just for fun (usually). Notably, it can lead to service downtime.
Do you have other ideas of how to address this situation? Have you run into odd ways of reaching this hard-coded limit? Contact us! We always love a good discussion about PostgreSQL.
]]>Statistics (in the broad sense: monitoring counters, I/O metrics, and planner / optimizer estimates) lie at the heart of both performance tuning and internal decision making in PostgreSQL. Transparent, reliable, and manipulable statistics, among other things, allow DBAs to address the efficiency of PostgreSQL directly, as well as enable “extensions” to improve the user experience.
That said, the historic statistics system of PostgreSQL has not been without points of friction. These include limited ability to clear (relations) statistics, metrics with units that don’t always align with user goals, and no C API for using the PostgreSQL Cumulative Stats engine. PostgreSQL 18 addresses these concerns head on.
Below is a summary of the key enhancements.
While statistics offer incredible value, their collection can take up significant time and resources. PostgreSQL 18 introduces an important consideration: with the expanded range of collectible metrics, the hash table maximum size has been increased. Do keep in mind, especially if you’re designing large-scale systems with table-per-customer architectures, that 1GB ceilings have been shown to be hit with some millions of tables.
Here are the major new or improved features relating to statistics and monitoring. Each item links to the relevant documentation or code where possible.
Generally, pg_stat_io now reports I/O activity in bytes rather than pages, which is more convenient for analysis. Moreover, WAL statistics were moved here from pg_stat_wal, providing a single, comprehensive view.
pg_upgrade is now able to retain optimizer statistics, removing the need to run a full ANALYZE on the databases to get good planning of queries after the upgrade; this is a very welcome update for large databases! Be aware that custom statistics added by an extension along with those created with CREATE STATISTICS won’t be retained.
You will surely want to look at new options in vacuumdb (--missing-stats-only) to, well, analyze only what’s needed.
On a similar note, the --[no-]statistics flag has been added to pg_dump, pg_dumpall, and pg_restore.
It’s now easier to know the maintenance effort on objects with total time spent on VACUUM and ANALYZE operation (and automatic ones) now reported into pg_stat_all_tables and variants.
A new GUC to not forget is track_cost_delay_timing. It collects time spent sleeping (due to delayed operations) for VACUUM and ANALYZE. While very interesting, like other track_io* GUCs, it implies a lot of extra calls to the system clock which on some platforms can lead to a severe performance impact. Always check with tool like pg_test_timing to ensure your system can afford it!
No more questions about checkpointer activity when using pg_stat_checkpointer. The new attribute num_done lets us know the number of completed checkpoints. You can also get what kind of buffers were written with slru_written and buffers_written now only matching shared_buffers: previously log and view were not providing the same counts because there was a SLRU counter in one case and not the other.
Want to know more about the I/O handled by the backend (PID)? Call pg_stat_get_backend_io(int) and you’ll get output similar to what the pg_stat_io view provides, for this process (excluding those already). As for the WAL stats for this PID: call pg_stat_get_backend_wal(int).
New attributes parallel_workers_to_launch and parallel_workers_launched were introduced in pg_stat_database. The ratio lets us know if we have enough slots for parallel workers.
Interesting changes on pg_stat_statements: more queries will be grouped under the same identifier. For example, patterns IN (1,2,3, ...) as only first and last constant will be used. A more counter-intuitive change is related to the table name used in a query. Only the name is used, not the schema or relation OID. This last change allows us to track dropped or recreated tables for example, but it will group statistics from unrelated tables if they have just the same name. The way to keep separate statistics for tables with same name is to alias them in the queries (FROM my.table mt, other.table ot)…
Finally, additions to pg_backend_memory_contexts with path (to get parent/child) and type to segregate AllocSet, Generation, Slab and Bump contexts… and what exactly are Slab and Bump? They are not documented; for these you’ll want to read headers of C files here. They exist to optimize memory allocation, reallocation, and reset, depending on expected memory usage. For example, Slab is defined as a «MemoryContext implementation designed for cases where large numbers of equally-sized objects can be allocated and freed efficiently with minimal memory wastage and fragmentation».
Ah, no, a last one, wal_buffers_full was added to pg_stat_statements to allow us to tune for wal_buffers with better insights.
There are now better insights for conflict management when using logical replication that leverage new attributes in pg_stat_subscription_stats. As reference, this excerpt from the commit entry lists the following attributes that were introduced:
confl_insert_exists:
Number of times a row insertion violated a NOT DEFERRABLE unique
constraint.
confl_update_origin_differs:
Number of times an update was performed on a row that was
previously modified by another origin.
confl_update_exists:
Number of times that the updated value of a row violates a
NOT DEFERRABLE unique constraint.
confl_update_missing:
Number of times that the tuple to be updated is missing.
confl_delete_origin_differs:
Number of times a delete was performed on a row that was
previously modified by another origin.
confl_delete_missing:
Number of times that the tuple to be deleted is missing.
There is now a new set of functions to manage relation and attributes stats (relpages, avg_width, and so on). This gives you the freedom to export, import, and adjust stats as you want, so you can replicate planner behavior outside of “production”, maintain patched stats, and so on.
One of the most exciting parts is what PostgreSQL 18 opens up for extension authors.
This tiny line at bottom of section E.1.3.9 Modules is what concerns these changes:
Allow extensions to use the server’s cumulative statistics API (Michael Paquier)
Previously statistics manipulation was an internal-only affair; now there is an official, structured API surface you can build on (or wrap).
The commit message is well written, and covers most of the new functionality. A subset of the options is detailed in the documentation. However, you will need to go into source code to know more at this stage; in particular, it’s worth having a look at the injection points extension (provided in core) which uses the new API.
For a deeper dive into how an extension can leverage these new capabilities, soon you will be able to see PACS (PostgreSQL Advanced Cumulative Statistics) on Codeberg - my project that provides a wrapper library and helper utilities around the new PostgreSQL 18 statistics APIs.
In the meantime, the talk I gave at FOSDEM 2025 explores these topics in greater detail.
]]>Once upon a time, in a faraway server room encased in heavy glass and reinforced concrete, lived a PostgreSQL database so confined, so secluded, it could only dream of the cloud.
No network.
No USB.
No writable external storage device.
Just a keyboard, a monitor, and the hum of industrial-grade air filters.
This wasn’t your average air-gapped setup. This was a zero-exfiltration zone, with operational security so tight you’d think it was guarding state secrets—or worse, legacy banking software.
And yet, in this digital oubliette, one innocent challenge remained:
How do you back up a PostgreSQL database without ever extracting a file?
Our customer didn’t just want backups—they needed them. The fear wasn’t theft, it was total failure: a motherboard dying quietly in its glass sarcophagus, taking the data with it. And if it came to that, chiseling through reinforced architecture wasn’t a viable disaster recovery plan.
We brainstormed everything:
psql output? Way too verbose.And then came the epiphany: QR codes.
What if we could pg_dump the database…
into QR codes…
on the screen…
captured by a high-speed camera…
then reassembled frame by frame outside the vault?
It was so absurd, it just might work.
pg_dump: Now with More PixelsPostgreSQL’s beloved pg_dump tool is modular. So we extended it with a custom archiver: --format=qrcode.
Here’s how it works:
QR encoding: Each chunk of SQL output is encoded into a PNG QR code.
Streaming: Instead of saving to disk, we push the stream of PNGs directly to stdout.
Framing: Our UI lays out multiple QR codes on a single screen using high-DPI output. (We’re talking 2000+ pixels here—room for a whole grid of codes.)
Playback: A dedicated machine with a 1280Hz high-speed camera films the screen, capturing the sequence as a video.
No keyboard macros. No sneaky uploads. Just photons and frames.
Once the video is extracted from the glass box:
Our parser watches the footage, frame by frame.
QR codes are detected and decoded in parallel.
Each chunk is sequence-tagged for ordering.
The resulting text is reassembled into a proper pg_dump.sql.
And just like that: the database lives again—fully exported with no digital transfer.
Only light and lenses.
QR Version: We used Version 40 QR codes (max capacity) with optimized binary mode for high density.
Error Correction: Level Q for resilience under compression/artifacts.
Screen Real Estate: 25×16 grid of codes per frame on a 1920×1080 pixel monitor—350 chunks per screen, around 1,016KB per frame.
Playback Rate: We achieved ~60 screens/sec = 21,000 chunks/sec, nearly 60MB/sec!.
Total Export Time: A full logical backup under 6GB was exported in less than 100 minutes!
This isn’t just a quirky story—it’s a reminder that PostgreSQL’s flexibility extends even into the absurd. Air-gapped systems aren’t rare in defense, finance, or critical infrastructure. And when normal tooling fails, PostgreSQL’s pluggable architecture gives you room to innovate, even in the tightest constraints.
We at Data Bene live for this kind of challenge. Whether it’s optimizing query plans or designing data exfiltration methods that look like spycraft, we’re here to help you make PostgreSQL dance—even when it’s stuck in a cage.
Want to try it yourself? Drop us a line—we love weird backups.
And if you’re thinking of streaming pg_restore into a laser light show, call us. We’re intrigued.
In this episode, we introduce the just-released open source extension StatsMgr, created to continuously monitor and track events across PostgreSQL and the underlying system. Here’s a look at what this episode covered:
Originally the idea was to provide a simplified interface for metrics, while enhancing them with a wide variety of available types. This functionality was then expanded to address problems like:
This extension, in turn, is great at handling situations like when…
Currently, supported statistics include:
Each of these is registered with a handler that lets you fetch and manage these statistics, and also is accompanied by shared memory structures for storing historical snapshots.
Some of the next steps for the project will include adding in dynamic statistics such as pg_stat_user_tables, amongst others.
There are still many things to do, from subtle improvements to major new features. So of course there’s many opportunities to contribute to the project, no matter if you’re a new-comer or an advanced PostgreSQL developer. Interested in being a part of the effort? Check out CONTRIBUTING.md within the project.
For an in-depth exploration of StatsMgr and its capabilities, watch the full episode here:
We still have much more to come for Postgres Café. Subscribe to the playlist for episodes that feature more open-source tools like pgroll for zero-downtime schema migrations, Citus Data for distributed and scalable PostgreSQL as an extension, and more. Watch this space to learn how each tool can make working with Postgres smoother and more efficient.
]]>This article results from a code review I did for a customer.
Our customer created a pg_dump --schema-only of the target database to provide
me with the plpgsql code and database object structures to review. So far
so good.
I started to read the code and then became puzzled. The code looks like this:
CREATE FUNCTION xxx( p_id character, p_info character varying )
RETURNS integer
LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
...
INSERT INTO t1
SELECT * FROM t2 WHERE t2.id = p_id;
...
END;
$$
;Maybe you saw nothing wrong with the function. Perhaps knowing the table
definition will help:
CREATE TABLE t2 (
id VARCHAR(130) NOT NULL
...
PRIMARY KEY (id)
);t2.id is always 130 characters long (in practice) and there are 400 million tuples.
So as you may have guessed, it seems odd to have the p_id CHARACTER matching id VARCHAR(130).
Moreover CHARACTER is the same as CHAR(1).
Our customer had not seen any issues with the code for years. Nevertheless, our customer told me that the function definition he wrote was not like that: it was meant to be p_id CHARACTER(130) - not CHARACTER.
So what went wrong? Let’s test around because it’s fun.
CREATE FUNCTION test( c character, d character varying )
RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
RAISE NOTICE 'c=%, d=%', c,d;
END;
$$;
SELECT test( '123465789', '987654321' );
NOTICE: c=123465789, d=987654321
test
------
(1 row)We have an interesting result here: no casting to CHAR(1) has been done.
Let’s see more details:
EXPLAIN (COSTS OFF,ANALYZE,VERBOSE)
SELECT test( '123465789', '987654321' );
NOTICE: c=123465789, d=987654321
QUERY PLAN
---------------------------------------------------------------------
Result (actual time=0.040..0.041 rows=1 loops=1)
Output: test('123465789'::bpchar, '987654321'::character varying)
Planning Time: 0.023 ms
Execution Time: 0.053 ms
(4 rows)We can see there was a cast to BPCHAR. As a reminder, BPCHAR is an alias of CHARACTER
and it can represent a string up to 10,485,760 characters.
Now let’s make another test:
CREATE FUNCTION test(c character(4))
RETURNS character(4)
LANGUAGE sql
AS $$
select c;
$$;As you can see, the language changed to SQL and the argument type and the return
type are CHAR(4). How does it execute?
SELECT test('123456789');
test
-----------
123456789
(1 row)
EXPLAIN VERBOSE SELECT test('123456789');
QUERY PLAN
-------------------------------------------
Result (cost=0.00..0.01 rows=1 width=32)
Output: '123456789'::bpchar
(2 rows)As you can see, even though you expect to process CHAR(4) data, you end up processing arbitrary length strings instead!!
However, do not rush to PostgreSQL mailing list to complain YET!
As a matter of fact, this behaviour is not a bug. The documentation states:
“The full SQL type syntax is allowed for declaring a function’s arguments and return value. However, parenthesized type modifiers (e.g., the precision field for type numeric) are discarded by CREATE FUNCTION. Thus for example CREATE FUNCTION foo (varchar(10)) … is exactly the same as CREATE FUNCTION foo (varchar) …”
This explains that CHARACTER(x) became CHARACTER aliased as BPCHAR. And as we saw, BPCHAR is not actually CHAR(1) but more like VARCHAR(10485760). This fully explains the behaviour.
Wait, wait , WAIT ! The original intention was to deal with CHAR(4) string - not any arbituary length strings.
Isn’t there any hope? No, sorry… (kidding.)
Reading the same documentation page, we see that “argtype” and “rettype” can be base, composite, or domain types, or can reference the type of a table column.
The trick is to create either a composite type or a domain to use as argtype or rettype.
Here are some examples:
-- Works in simple case trick
SELECT test( '12345789'::char(4) );
-- Domain trick
CREATE DOMAIN c4 AS char(4);
CREATE FUNCTION test(param c4)
RETURNS c4
AS $$
BEGIN
RAISE NOTICE 'param=%', param;
RETURN param;
END;
$$ LANGUAGE plpgsql;
SELECT test( '123456789' );
ERROR: value too long for type character(4)
SELECT test( '123456789'::char(4) );
NOTICE: param=1234
test
------
1234
(1 row)
SELECT test( '123456789'::c4);
NOTICE: param=1234
test
------
1234
(1 row)
SELECT pg_typeof( test( '123456789'::char(4) ) );
NOTICE: param=1234
pg_typeof
-----------
c4
(1 row)Now you should be happy with the result.
What? Not yet? Ok here is an additional trick.
-- Map a table structure
CREATE TABLE qq ( c char(4));
CREATE FUNCTION test(IN c qq, OUT d qq)
LANGUAGE sql
AS $$
SELECT c;
$$;
SELECT * FROM test(ROW('12345'));
ERROR: value too long for type character(4)
SELECT * from test(ROW('1234'));
c
------
1234Hmm, OK, but how is this is different from the domain trick?
-- Easy Type Alteration
ALTER TABLE qq ALTER c TYPE char(5);
SELECT * FROM test( ROW('12345') );
c
-------
12345Try to ALTER a domain - you will see how (not) easy it is.
The table definition trick allows for some flexibility as follows:
ALTER TABLE qq ADD ee int;
SELECT test( ROW('12345', 4) );
test
----------
(12345,4)
SELECT * FROM test( ROW('12345', 4) );
c | ee
-------+----
12345 | 4We hope you enjoyed this article and that you learnt something new and interesting!
]]>