On 4/5/20 10:51 AM, arden liu wrote: > Does that RETURNING need any user input?
No. I just think actually returning those thousands of values is stalling the shell. It also not really necessary for the loading as 'INSERT 0 4333' shows you what you need to know. Unless you have super vision and recall you are not going to track those values anyway. You can verify in the table itself.
I would see if you could get the project to output the file using COPY to load the tables instead of INSERT anyway. The file is pretty much Postgres specific anyway as it doing things like:
1) DROP SCHEMA public CASCADE; create SCHEMA public;
SET statement_timeout = 0; SET client_encoding = 'UTF8'; -- HF - must have conforming strings on for Postgres interface to work, as it will include Windows paths sometimes SET standard_conforming_strings = on; SET check_function_bodies = false; SET client_min_messages = warning; SET escape_string_warning = off;
SET search_path = public, pg_catalog;
2) ALTER TYPE public.ancestry OWNER TO postgres;
> > On Sun., Apr. 5, 2020, 1:10 p.m. Adrian Klaver, > <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote: > > On 4/5/20 9:46 AM, Adrian Klaver wrote: > > On 4/5/20 5:50 AM, arden liu wrote: > > > 4) I don't see anything wrong the statements, so I am wondering > if it is > > a shell issue? > > Seems to be. I removed the RETURNING *_id from the INSERT statements > and > the file ran without interruption: > > ... > CREATE TABLE > ALTER TABLE > INSERT 0 4333 > INSERT 0 9326 > INSERT 0 13 > ALTER TABLE > ALTER TABLE > ... > > > > > > > > >> Thanks. > >> Arden > > > > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com> >
