Why to create empty (no rows, no columns) table in PostgreSQL

Question

In answer to this question I've learned that you can create empty table in PostgreSQL.

create table t();

Is there any real use case for this? Why would you create empty table? Because you don't know what columns it will have?

Answer 1

These are the things from my point of view that a column less table is good for. They probably fall more into the warm and fuzzy category.

1. One practical use of creating a table before you add any user defined columns to it is that it allows you to iterate fast when creating a new system or just doing rapid dev iterations in general.

2. Kind of more of 1, but lets you stub out tables that your app logic or procedure can make reference too, even if the columns have yet to be put in place.

3. I could see it coming in handing in a case where your at a big company with lots of developers. Maybe you want to reserve a name months in advance before your work is complete. Just add the new column-less table to the build. Of course they could still high jack it, but you may be able to win the argument that you had it in use well before they came along with their other plans. Kind of fringe, but a valid benefit.

All of these are handy and I miss them when I'm not working in PostgreSQL.

Answer 2

I don't know the precise reason for its inclusion in PostgreSQL, but a zero-column table - or rather a zero-attribute relation - plays a role in the theory of relational algebra, on which SQL is (broadly) based.

Specifically, a zero-attribute relation with no tuples (in SQL terms, a table with no columns and no rows) is the relational equivalent of zero or false, while a relation with no attributes but one tuple (SQL: no columns, but one row, which isn't possible in PostgreSQL as far as I know) is true or one. Hugh Darwen, an outspoken advocate of relational theory and critic of SQL, dubbed these "Table Dum" and "Table Dee", respectively.

In normal algebra x + 0 == x and x * 0 == 0, whereas x * 1 == x; the idea is that in relational algebra, Table Dum and Table Dee can be used as similar primitives for joins, unions, etc.

PostgreSQL internally refers to tables (as well as views and sequences) as "relations", so although it is geared around implementing SQL, which isn't defined by this kind of pure relation algebra, there may be elements of that in its design or history.