Postgres database pg_dump - dump file verbosity explanation - postgresql

Question

I created a postgres database dump with pg_dump. I would like to now why the backup file is so verbose.
a) What is the purpose of this config:
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;
SET default_tablespace = '';
SET default_table_access_method = heap;
b) Why is a creation of a table so verbose:
CREATE TABLE public.tag (
id integer NOT NULL,
name character varying(100) NOT NULL,
description text
);
ALTER TABLE public.tag OWNER TO postgres;
CREATE SEQUENCE public.tag_id_seq
AS integer
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE public.tag_id_seq OWNER TO postgres;
ALTER SEQUENCE public.tag_id_seq OWNED BY public.tag.id;
ALTER TABLE ONLY public.tag ALTER COLUMN id SET DEFAULT nextval('public.tag_id_seq'::regclass);
Why not just like I created it before:
CREATE TABLE tag (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
description TEXT
);
c) Why is COPY ... FROM stdin; used rather than INSERT INTO ... VALUES ?
COPY public.tag (id, name, description) FROM stdin;
1 vegetarian No animals.
2 vegan No animal products.
3 vegetable
\.
SELECT pg_catalog.setval('public.tag_id_seq', 3, true);
ALTER TABLE ONLY public.tag
ADD CONSTRAINT tag_pkey PRIMARY KEY (id);

Answer 1

I would suggest spending some time here pg_dump. In mean time:
a) That sets up the database environment to be compatible with the database you dumped from. Also a security feature SELECT pg_catalog.set_config('search_path', '', false); See here CVE-2018-1058 for more on that.
b) This is because a dump has three parts 'pre-data, data, post-data`. See link above for complete explanation. By default it will dump all three, but keeps the parts separate. It also allows for things like triggers that work best if restored separately and later so they are not running when inputting the data.
c) COPY is orders of magnitude faster then INSERTS. You can specify using INSERTS, but I would recommend not unless you are moving data to another SQL database that does not understand COPY.