From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Färber, Franz-Josef (StMUK) <Franz-Josef(dot)Faerber(at)stmuk(dot)bayern(dot)de>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: COPY TO (query) allows no function arguments |
Date: | 2021-03-10 15:45:07 |
Message-ID: | CAKFQuwa9KTE+sYuDzCbbh9Ae8aJRsmTpqs_bOK-6XnMfYmV7RA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Mar 10, 2021 at 8:17 AM Joe Conway <mail(at)joeconway(dot)com> wrote:
> EXECUTE $$COPY (SELECT * FROM $$ || myparam || $$) TO '/tmp/a.txt'$$;
>
This is not the same command as originally presented, in particular this
uses myparam as an identifier (which can never be a variable) while the
original used myparam as a value (which usually can be a variable). That
said I'm not sure at the moment where exactly the breakdown is that results
in myparam being checked as a column name (and thus not found) instead of
as a variable name (and thus found and replaced with a literal, which
SELECT can handle just fine).
If COPY itself can be parameterized/prepared (I'm unsure and not able to
test right now) then it should be able to accept variables when used in a
function - within the rules for variable substitution.
David J.
As an aside, the format() combined with EXECUTE in pl/pgsql is much more
readable as well as makes preventing SQL injection trivial.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-03-10 16:46:51 | Re: COPY TO (query) allows no function arguments |
Previous Message | Joe Conway | 2021-03-10 15:17:07 | Re: COPY TO (query) allows no function arguments |