Whenever people look for help with queries, one of the first things that I ask is: what is \d of the table.
Which works great, with the caveat, that the person on the other end must be somewhat familiar with psql. And quite often it's not the case.
So I figured, I can try to fix it.
Based on this I made psql-backslash.
It's a pure pl/PgSQL set of functions that are supposed to generate output that is directly compatible with what various \* commands generate.
For now, it contains only two useful functions:
- select psql.d(); – should return the same as \d (without arguments) in psql
- select psql.d(‘table_name'); – should return the same as \d table_name in psql
For example, you can:
=$ psql -qAtX -d depesz_cards -c "select psql.d()" List OF relations Schema | Name | TYPE | Owner --------+---------------------+-------------------+-------------- public | game_types | TABLE | depesz_cards public | games | TABLE | depesz_cards public | games_id_seq | SEQUENCE | depesz_cards public | players | TABLE | depesz_cards public | stats_longest_games | materialized VIEW | depesz_cards public | stats_winners | materialized VIEW | depesz_cards public | users | TABLE | depesz_cards (7 ROWS) =$ psql -qAtX -d depesz_cards -c "select psql.d('games')" TABLE "public.games" COLUMN | TYPE | Collation | NULLABLE | DEFAULT -------------+--------------------------+-----------+----------+------------------------------ id | BIGINT | | NOT NULL | generated always AS IDENTITY game_type | text | | | created_at | TIMESTAMP WITH TIME zone | | | updated_at | TIMESTAMP WITH TIME zone | | | game_data | jsonb | | | finished_at | TIMESTAMP WITH TIME zone | | | players_set | text | | | Indexes: "games_pkey" PRIMARY KEY, btree (id) Foreign-KEY constraints: "games_game_type_fkey" FOREIGN KEY (game_type) REFERENCES game_types(type_name) Triggers: trg_timestamps_games BEFORE INSERT OR UPDATE ON games FOR EACH ROW EXECUTE FUNCTION trg_timestamps()
Obviously, this is just first release, there are a lot of things that don't work, or aren't displayed properly.
But it's a start. And I hope I will be able to update it with bugfixes and new functionalities.
As for installation – within the repo there is full.create.sql file which, when you'll load it to your DB, will make all that is needed. Or update, if needed.
If you'd prefer to have it in some other schema than psql, you can do it using scripts/build.full.sql.sh script.
Hope you'll find it useful 🙂