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@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
