From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow COPY to use parameters |
Date: | 2016-05-27 07:17:17 |
Message-ID: | 87iny0htrr.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Merlin" == Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
Merlin> Note, the biggest pain point I have with COPY is not being able
Merlin> to parameterize the filename argument.
Second proof of concept attached. This goes so far as to allow
statements like:
do $$
declare t text := 'bar'; f text := '/tmp/copytest.dat';
begin copy (select t, now()) to (f) csv header; end;
$$;
Also "copy foo to $1" or "copy (select * from foo where x=$1) to $2" and
so on should work from PQexecParams or in a plpgsql EXECUTE.
(I haven't tried to parameterize anything other than the filename and
query. Also, it does not accept arbitrary expressions - only $n, '...'
or a columnref. $n and '...' can have parens or not, but the columnref
must have them due to conflicts with unreserved keywords PROGRAM, STDIN,
STDOUT. This could be hacked around in other ways, I guess, if the
parens are too ugly.)
--
Andrew (irc:RhodiumToad)
Attachment | Content-Type | Size |
---|---|---|
copyparam2.patch | text/x-patch | 16.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2016-05-27 08:38:05 | Re: Parallel pg_dump's error reporting doesn't work worth squat |
Previous Message | Amit Kapila | 2016-05-27 07:07:03 | Re: PATCH: pg_restore parallel-execution-deadlock issue |