Postgres and Void

Just came across the possibility of Postgresql, which seemed funny to me. For whom the "button accordion" is respect for you, I have been working with Postgres for several years and have not stumbled upon such a thing so far.

select; without specifying fields, tables, and conditions, returns one row. But this line has no fields:

 => select; -- (1 row) 

For comparison:

 => select null; ?column? ---------- (1 row) => select null where 0=1; ?column? ---------- (0 rows) 

Can we create a table from such an "empty" query? Borderless table

Yes please:

 => create table t as select; SELECT 1 => \d+ t Table "t" Column | Type | Modifiers | Storage | Stats target | Description --------+------+-----------+---------+--------------+------------- => select * from t; -- (1 row) 

And can we insert into it?
Easy:

 => insert into t select; INSERT 0 1 => insert into t select; INSERT 0 1 => select * from t; -- (3 rows) => select count(*) from t; count ------- 3 

STILL!

 => insert into t select from generate_series(1,1000000); INSERT 0 1000000 

I wonder if Postgresql will scan such a table?

 => explain analyze select * from t; QUERY PLAN ------------------------------------------------------------------------------------------------------------ Seq Scan on t (cost=0.00..13438.67 rows=1000167 width=0) (actual time=0.018..96.389 rows=1000003 loops=1) Planning time: 0.024 ms Execution time: 134.654 ms (3 rows) 

Yes, honestly scans. More than 100 ms is quite a noticeable time.
Well, to make sure everything is fair, let's see how much space our super-useful table takes:

 => select pg_size_pretty(pg_total_relation_size('t')); pg_size_pretty ---------------- 27 MB (1 row) 

That is, the table is there, it takes up space on the disk, different service data is stored in the blocks, well, the fact that there are no fields in it - it happens, it’s everyday!

 => select t.xmin, t.ctid from t limit 10; xmin | ctid ---------+-------- 1029645 | (0,1) 1029647 | (0,2) 1029648 | (0,3) 1029649 | (0,4) 1029649 | (0,5) 1029649 | (0,6) 1029649 | (0,7) 1029649 | (0,8) 1029649 | (0,9) 1029649 | (0,10) (10 rows) 

I did not think of why such a table might be needed. But the opportunity is there, and that's good!
I am using Postgresql 9.6. As noted below in lower versions this does not work. In 9.3 produces syntax error . 9.4, 9.5 is not at hand to check.